Immediate policy effectiveness in eventually consistent systems

ABSTRACT

Policy changes are propagated to access control devices of a distributed system. The policy changes are given immediate effect without having to wait for the changes to propagate through the system. A token comprises the policy change and can be provided in connection with access requests. Before an access control device has received a propagated policy change, the access control device can evaluate a token provided in connection with a request to determine, consistent with the policy change, whether to fulfill the request.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.15/851,564, filed on Dec. 21, 2017, entitled “IMMEDIATE POLICYEFFECTIVENESS IN EVENTUALLY CONSISTENT SYSTEMS”, which is a continuationof U.S. application Ser. No. 13/794,549, filed on Mar. 11, 2013,entitled “IMMEDIATE POLICY EFFECTIVENESS IN EVENTUALLY CONSISTENTSYSTEMS,” the contents of which are incorporated by reference herein intheir entireties.

BACKGROUND

Data security is an important aspect of operating various computersystems. Distributed systems provide particular challenges. For example,a distributed system may comprise multiple individual computer systemsthat communicate with one another over a network. The individualcomputer systems may be spread out over a data center or even multipledata centers. As a result, effective control of access to the variouscomputer systems and the data they store (generally, computingresources) can be quite difficult. A security-related configurationchange may, for example, take effect at different times in thedistributed system, which may lead to inconsistent enforcement, at leastfor a period of time. In addition, waiting for configuration changes totake effect throughout a distributed system may be inconvenient forusers of the distributed system.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1 shows an illustrative diagram representing various aspects of thepresent disclosure in accordance with various embodiments;

FIG. 2 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented;

FIG. 3 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented and an example flowof information among the various components of the environment inaccordance with at least one embodiment;

FIG. 4 shows example steps of an illustrative process for storingciphertext, in accordance with at least one embodiment;

FIG. 5 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented and an example flowof information among the various components of the environment inaccordance with at least one embodiment;

FIG. 6 shows example steps of an illustrative process for responding toa request to retrieve data, in accordance with at least one embodiment;

FIG. 7 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented and an example flowof information among the various components of the environment inaccordance with at least one embodiment;

FIG. 8 shows example steps of an illustrative process for responding toa request to store data, in accordance with at least one embodiment;

FIG. 9 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented and an example flowof information among the various components of the environment inaccordance with at least one embodiment;

FIG. 10 shows example steps of an illustrative process for responding toa request to retrieve data, in accordance with at least one embodiment;

FIG. 11 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented;

FIG. 12 shows an illustrative example of an environment in which variousaspects of the present disclosure may be implemented and an example flowof information among the various components of the environment inaccordance with at least one embodiment;

FIG. 13 shows example steps of an illustrative process for responding toa request to retrieve data, in accordance with at least one embodiment;

FIG. 14 shows example steps of an illustrative process for responding toa request to decrypt data, in accordance with at least one embodiment;

FIG. 15 shows example steps of an illustrative process for obtainingdecrypted data, in accordance with at least one embodiment;

FIG. 16 shows a diagrammatic representation of an example cryptographyservice, in accordance with at least one embodiment;

FIG. 17 shows example steps of an illustrative process for configuringpolicy, in accordance with at least one embodiment;

FIG. 18 shows example steps of an illustrative process for performingcryptographic operations while enforcing policy, in accordance with atleast one embodiment;

FIG. 19 shows an illustrative example of a process for encrypting datain accordance with at least one embodiment;

FIG. 20 shows an illustrative example of using a security module toencrypt data in accordance with at least one embodiment;

FIG. 21 shows an illustrative example of using a security module toencrypt a key used to encrypt data in accordance with at least oneembodiment;

FIG. 22 shows an illustrative example of a process for enforcing policyusing associated data in accordance with at least one embodiment;

FIG. 23 shows an illustrative example of a process for enforcing policyusing associated data and a security module in accordance with at leastone embodiment;

FIG. 24 shows an illustrative example of an environment in which variousembodiments may be implemented;

FIG. 25 shows another illustrative example of an environment in whichvarious embodiments may be implemented;

FIG. 26 shows an illustrative example of a process for processing arequest and providing a token in accordance with at least oneembodiment;

FIG. 27 shows an illustrative example of a process for utilizing acryptography service in accordance with at least one embodiment;

FIG. 28 shows an illustrative example of a process for processing apolicy change and a request in accordance with at least one embodiment;

FIG. 29 shows an illustrative example of an environment in which variousembodiments may be implemented;

FIG. 30 shows an illustrative example of a process for processing arequest in accordance with policy in accordance with at least oneembodiment; and

FIG. 31 illustrates an environment in which various embodiments can beimplemented.

DETAILED DESCRIPTION

In the following description, various embodiments will be described. Forpurposes of explanation, specific configurations and details are setforth in order to provide a thorough understanding of the embodiments.However, it will also be apparent to one skilled in the art that theembodiments may be practiced without the specific details. Furthermore,well-known features may be omitted or simplified in order not to obscurethe embodiment being described.

Techniques described and suggested herein allow for enhanced datasecurity in environments involving distributed computing resources. Inone example, a distributed computing environment includes one or moredata services which may be implemented by appropriate computingresources. The data services may allow various operations to beperformed in connection with data. As one illustrative example, thedistributed computing environment includes one or more data storageservices. Electronic requests may be transmitted to the data storageservice to perform data storage operations. Example operations areoperations to store data using the data storage service and using thedata storage service to retrieve data stored by the data storageservice. Data services, including data storage services, may alsoperform operations that manipulate data. For example, in someembodiments, a data storage service is able to encrypt data.

Various embodiments of the present disclosure include distributedcomputing environments that include cryptography services that areimplemented using appropriate computing resources. A cryptographyservice may be implemented by a distributed system that receives andresponds to electronic requests to perform cryptographic operations,such as encryption of plaintext and decryption of ciphertext. In someembodiments, a cryptography service manages keys. In response to arequest to perform a cryptographic operation, the cryptography servicemay execute cryptographic operations that use the managed keys. Forexample, the cryptography service can select an appropriate key toperform the cryptographic operation, perform the cryptographicoperation, and provide one or more results of the cryptographicoperation in response to the received request. In an alternativeconfiguration, the cryptography service can produce an envelope key(e.g., a session key that is used to encrypt specific data items) andreturn the envelope key to the system invoking the cryptographicoperations of the service. The system can then use the envelope key toperform the cryptographic operation.

In some embodiments, the cryptography service manages keys for multipletenants of a computing resource service provider. A tenant of thecomputing resource may be an entity (e.g. organization or individual)operating as a customer of the computing resource provider. The customermay remotely and programmatically configure and operate resources thatare physically hosted by the computing resource provider. When acustomer submits a request to the cryptography service to perform acryptographic operation (or when an entity submits a request to thecryptography service), the cryptography service may select a key managedby the cryptography service for the customer to perform thecryptographic operation. The keys managed by the cryptography servicemay be securely managed so that other users and/or data services do nothave access to the keys of others. A lack of access by an entity (e.g.,user, customer, service) to the key of another entity may mean that theentity does not have an authorized way of obtaining the key of the otherand/or that the entity does not have an authorized way of causing asystem that manages the key of the other of using the key at theentity's direction. For example, the cryptography service may managekeys so that, for a customer, other customers both do not have access tothe customer's key(s) and are unable to cause the cryptography serviceto use the customer's key(s) to perform cryptographic operations. Asanother example, the cryptography service may manage keys so that otherservices, such as a data storage service, are unable to cause thecryptography service to use some or all keys to perform cryptographicoperations. Unauthorized access to a key may be prevented by appropriatesecurity measures so that, for example, unauthorized access is difficultor impossible. Difficulty may be due to computational impracticalityand/or due to a need for an unauthorized (e.g., illegal, tortious and/orotherwise disallowed such as a. compromise of authorization credentials)to occur for access to be gained. Systems in accordance with the variousembodiments may be configured to ensure an objective measure ofcomputational impracticality to gain access to a key. Such measures maybe, for example, measured in terms of an amount of time, on average, itwould take a computer having a defined unit of computational ability(e.g. certain operations per unit of time) to crack encryptedinformation needed for authorized access to the key.

As noted, a cryptography service may receive requests from variousentities, such as customers of a computing resource provider. Acryptography service may also receive requests from entities internal tothe computing resource provider. For example, in some embodiments, dataservices implemented by the computing resource provider may transmitrequests to a cryptography service to cause the cryptography service toperform cryptographic operations. As one example, a customer maytransmit a request to a data storage service to store a data object. Therequest may indicate that the data object should be encrypted whenstored. The data storage service may communicate a request to acryptography service to perform a cryptographic operation. Thecryptographic operation may be, for example, encryption of a key used bythe data storage service to encrypt the data object. The cryptographicoperation may be encryption of the data object itself. The cryptographicoperation may be to generate an envelope key that the data storageservice can use to encrypt the data object.

Systems in accordance with the various embodiments implement varioussecurity measures to provide enhanced data security. For example, invarious embodiments, the manner in which a cryptography service canutilize keys it manages is limited. For example, in some embodiments, acryptography service is configured to only use a key corresponding to acustomer upon appropriate authorization. If a request to use acustomer's key purportedly originates from the customer (i.e., from acomputing device operating on behalf of the customer), the cryptographyservice may be configured to require that the request be electronically(digitally) signed using appropriate credentials owned by the customer.If the request to use the customer's key originated from another dataservice, the cryptography service may be configured to require that thedata service provide proof that a signed request to the data service hasbeen made by the customer. In some embodiments, for example, the dataservice is configured to obtain and provide a token that serves as proofof an authenticated customer request. Other security measures may alsobe built into a configuration of an electronic environment that includesa cryptography service. For example, in some embodiments, a cryptographyservice is configured to limit key use according to context. As oneillustrative example, the cryptography service may be configured to usea key for encryption for requests from a customer or from a data serviceacting on behalf of the customer. However, the cryptography service maybe configured to only use a key for decryption for requests from thecustomer (but not from another data service). In this manner, if thedata service is compromised, the data service would not be able to causethe cryptography service to decrypt data.

Various security measures may be built into a cryptography serviceand/or its electronic environment. Some security measures may be managedaccording to policies which, in some embodiments, are configurable. Asone example, a cryptography service may utilize an applicationprogramming interface (API) that enables users to configure policies onkeys. A policy on a key may be information that, when processed by acryptography service, is determinative of whether the key may be used incertain circumstances. A policy may, for instance, limit identities ofusers and/or systems able to direct use of the key, limit times when thekey can be used, limit data on which the key can be used to performcryptographic operations on, and provide other limitations. The policiesmay provide explicit limitations (e.g., who cannot use the keys) and/ormay provide explicit authorizations (e.g., who can use the keys).Further, policies may be complexly structured to generally provideconditions for when keys can and cannot be used. When a request toperform a cryptographic operation using a key is received, any policieson the key may be accessed and processed to determine if the requestcan, according to policy, be fulfilled.

Various embodiments of the present disclosure are related to theenforcement of policy associated with keys, where the keys may bemanaged by a cryptography service. Users of the cryptography service,such as customers of a computing resource provider hosting thecryptography service, may specify policies on keys to be enforced by thecryptography service. The policies may encode restrictions and/orprivileges in connection with who can direct the cryptography service touse the keys, what operations the keys can be used to perform, in whichcircumstances the key can be used and/or other key uses.

In an embodiment, data associated with ciphertext is used in theenforcement of policy. The data associated with the ciphertext may bedata that is obtained through use of a cipher, such as modes of theadvanced encryption standard (AES). For example, input to acryptographic algorithm may include plaintext to be encrypted andassociated data. The cryptographic algorithm may use a key to encryptthe plaintext and provide authentication output, such as a messageauthentication code (MAC) that enables a determination whether theassociated data has been altered. The authentication output may bedetermined based at least in part on the associated data and theplaintext.

Policy enforcement may be based at least in part on associated data. Forexample, some policies may require associated data to have a particularvalue before decrypted ciphertext (i.e., plaintext) is provided. Theauthentication output (e.g., MAC) may be used to ensure that theassociated data has not been altered and, therefore, that enforcement ofthe policy is performed correctly. The associated data may be anysuitable data, and the data itself may be specified explicitly orimplicitly by policy. For example, a policy may specify that decryptedciphertext (plaintext) can be provided only if a request to decrypt theciphertext is submitted by a user having a user identifier encoded inassociated data used to encrypt the ciphertext. In this manner, ifanother user requests decryption of the ciphertext (withoutimpersonating the user having the user identifier), the request will notbe fulfilled due to a conflict with policy. As another example, a policymay state that decrypted ciphertext can be provided only if theciphertext is tagged with specified information. As yet another example,a policy may state that decrypted ciphertext may be provided if taggedwith associated data equal to a hash of the plaintext, hash of theciphertext, or other specified values. Generally, embodiments of thepresent disclosure allow for rich policy enforcement around the input oroutput of a cryptographic algorithm before output of the cryptographicalgorithm is revealed. In some embodiments, associated data can itselfrepresent policy.

Various embodiments of the present disclosure also allow for policyaround key use. For instance, in some embodiments, keys areautomatically rotated to prevent the keys from being used enough time toenable successful cryptographic attacks that can reveal the keys. Toprevent a key from being used enough times to result in a potentialsecurity breach, a cryptography service or other system utilizing keysmay track operations performed with keys. When a key identified by a keyidentifier (KeyID) is used in a threshold number of operations, the keymay be retired (e.g., unusable for future encryption operations, butusable for future decryption operations) and replaced with a new key tobe identified by the KeyID. In this manner, new keys are produced in atimely basis. Further, various embodiments of the present disclosureperform such key rotation in a manner that is transparent to certainentities. As one example, a customer of a computing resource provider orother entity may submit requests to a cryptography service to performoperations using a key identified by a KeyID. The cryptography servicemay perform key rotation independent of any request from the entity toperform the key rotation. From the point of view of the customer orother entity, requests may still be submitted using a specified KeyIDwithout any reprogramming or other reconfiguration necessary due to akey having been retired and replaced with a new key.

In some embodiments, multiple systems supporting a cryptography or otherservice simultaneously have access to keys and are used to fulfillrequests to perform cryptographic operations. For example, acryptography service may utilize a cluster of security modules, at leastsome of which redundantly store one or more keys. The service mayallocate operations to the security modules and maintain its owncounter. When a security module uses its allocation (e.g., performs anallocated number of operations using a key), the service may checkwhether the key is still usable or whether the key should be retired. Itshould be noted that security modules (or other computer systems) may beconfigured to perform multiple types of operations using a key, such asencryption, decryption, electronic signature generation, and the like.In some embodiments, not all types of operations cause a security moduleto use a portion of an allocation of operations. For example, decryptionoperations may not result in allocated operations being used whereasencryption operations may result in allocated operations used.Generally, in various embodiments, cryptographic operations that resultin generation of new information (e.g., ciphertexts and/or electronicsignatures) may result in allocated operations being used whereascryptographic operations that do not result in the generation of newinformation may not result in allocated operations being used. Further,different types of operations may result in different numbers ofcryptographic operations being performed. As one example, encryption ofplaintexts may vary in the amount of cryptographic operations requiredbased at least in part on the size of the plaintexts. Use of blockciphers, for instance, may cause an allocated cryptographic operation tobe used for each block of ciphertext generated.

If a total number of operations available for a key is still usable, theservice may allocate additional operations to the security module. Ifthe key should be retired (e.g., because a counter so indicates), theservice may cause security modules that redundantly store the key toretire the key and replace the key with a new key, where the new key maybe generated or otherwise obtained by one security module and securelypassed to the remaining security modules. In some embodiments, othersecurity modules instead use up their allocated operations under theolder key. If a security module malfunctions, becomes inoperable, isintentionally taken offline (e.g., for maintenance) and/or otherwisebecomes unavailable for performing cryptographic operations withoutproviding information regarding how many operations it has performedusing one or more keys, the service may treat the unavailability as useof its allocation. For example, if a security module is allocated onemillion operations for each key in a set of keys, and the securitymodule becomes inoperable, the service may operate as if the securitymodule performed one million operations for each of the set of keys. Forexample, the service may allocate additional operations to the securitymodule or another security module, adjusting a counter accordingly,and/or may cause one or more of the keys to be retired and replaced,should corresponding counters indicate that replacement is necessary.

FIG. 1 is an illustrative diagram 100 demonstrating various embodimentsof the present disclosure. In an embodiment, a cryptography serviceperforms cryptographic operations which may include application of oneor more calculations in accordance with one or more cryptographicalgorithms. As illustrated in FIG. 1, the cryptography service enables auser or a service to generate plaintext from ciphertext. In an exampleconfiguration the cryptographic service can be used to encrypt/decryptkeys and these keys can be used to encrypt/decrypt data, such as datastored in a data storage service. For example, the cryptography servicereceives a request to generate plaintext from ciphertext encrypted undera key. The cryptography service determines that the requestor is anauthorized entity; decrypts the key using a master key and returns thenow decrypted key to the service, which can generate plaintext from theciphertext using the decrypted key. In another configuration, thecryptography service receives ciphertext and processes the receivedciphertext into plaintext which is provided as a service by thecryptography service. In this example, the ciphertext may be provided tothe cryptography service as part of an electronic request to thecryptography service from an authorized entity, which may be a customerof a computing resource provider that operates the cryptography serviceand/or which may be another service of the computing resource provider.The cryptography service illustrated in FIG. 1 may utilize one or morecryptographically strong algorithms to encrypt data. Suchcryptographically strong algorithms may include, for example, AdvancedEncryption Standard (AES), Blowfish, Data Encryption Standard (DES),Triple DES, Serpent or Twofish, and depending on the specificimplementation selected, may be either asymmetric or symmetric keysystems. Generally, the cryptography service may utilize any encryptionand/or decryption algorithm (cipher) or combination of algorithms thatutilizes data managed by the cryptography service.

As will be discussed below in more detail, the cryptography service canbe implemented in a variety of ways. In an embodiment, the cryptographyservice is implemented by a computer system configured in accordancewith the description below. The computer system may itself comprise oneor more computer systems. For example, a cryptography service may beimplemented as a network of computer systems collectively configured toperform cryptographic operations in accordance with the variousembodiments. Or put another way, the computer system could be adistributed system. In an embodiment, ciphertext is information that hasbeen encrypted using a cryptographic algorithm. In the example of FIG.1, the ciphertext is the plaintext in an encrypted form. The plaintextmay be any information and while the name includes no word text,plaintext and ciphertext may be information encoded in any suitable formand does not necessarily include textual information but it may includetextual information. For example, as illustrated in FIG. 1, plan textand ciphertext comprise sequences of bits. Plaintext and ciphertext mayalso be represented in other ways and generally in any manner by whichencryption and decryption can be performed by a computer system.

FIG. 2 shows an illustrative example of an environment 200 in which acryptography service, such as illustrated in FIG. 1, may be implemented.In the environment of 200, various components operate together in orderto provide secure data related services. In this particular example, theenvironment 200 includes a cryptography service, an authenticationservice, a data service frontend and a data service backend storagesystem. In an embodiment, the cryptography service is configured in theenvironment 200 to perform cryptographic operations, such as byreceiving plaintext from a data service frontend and providingciphertext in return or providing envelope keys to services, so that theservices can use the envelope keys to perform encryption operations. Thecryptography service may perform additional functions, such as describedbelow, such as secure storage of keys for performance of cryptographicoperations, such as converting plaintext into ciphertext and decryptingciphertext into plaintext. The cryptography service may also performoperations involved in policy enforcement, such as by enforcing policyassociated with keys stored therein. Example policies that may beenforced by a cryptography service are provided below. The data servicefrontend in an embodiment is a system configured to receive and respondto requests transmitted over a network from various users. The requestsmay be requests to perform operations in connection with data stored orto be stored in the data service backend storage system. In theenvironment 200, the authentication service, cryptography service, dataservice frontend and data service backend storage system may be systemsof a computing resource provider that utilizes the systems to provideservices to customers represented by the users illustrated in FIG. 2.The network illustrated in FIG. 2 may be any suitable network orcombination of networks, including those discussed below.

The authentication service in an embodiment is a computer systemconfigured to perform operations involved in authentication of theusers. For instance, the data service frontend may provide informationfrom the users to the authentication service to receive information inreturn that indicates whether or not the user requests are authentic.Determining whether user requests are authentic may be performed in anysuitable manner and the manner in which authentication is performed mayvary among the various embodiments. For example, in some embodiments,users electronically sign messages transmitted to the data servicefrontend. Electronic signatures may be generated using secretinformation (e.g., a private key of a key pair associated with a user)that is available to both an authenticating entity (e.g., user) and theauthentication service. The request and signatures for the request maybe provided to the authentication service which may, using the secretinformation, compute a reference signature for comparison with thereceived signature to determine whether the request is authentic. If therequest is authentic, the authentication service may provide informationthat the data service frontend can use to prove to other services, suchas the cryptography service, that the request is authentic, therebyenabling the other services to operate accordingly. For example, theauthentication service may provide a token that another service cananalyze to verify the authenticity of the request. Electronic signaturesand/or tokens may have validity that is limited in various ways. Forexample, electronic signatures and/or tokens may be valid for certainamounts of time. In one example, electronic signatures and/or tokens aregenerated based at least in part on a function (e.g., a Hash-basedMessage Authentication Code) that takes as input a timestamp, which isincluded with the electronic signatures and/or tokens for verification.An entity verifying a submitted electronic signature and/or token maycheck that a received timestamp is sufficiently current (e.g. within apredetermined amount of time from a current time) and generate areference signature/token using for the received timestamp. If thetimestamp used to generate the submitted electronic signature/token isnot sufficiently current and/or the submitted signature/token andreference signature/token do not match, authentication may fail. In thismanner, if an electronic signature is compromised, it would only bevalid for a short amount of time, thereby limiting potential harm causedby the compromise. It should be noted that other ways of verifyingauthenticity are also considered as being within the scope of thepresent disclosure.

The data service backend storage system in an embodiment is a computersystem that stores data in accordance with requests received through thedata service frontend. As discussed in more detail below, the dataservice backend storage system may store data in encrypted form. Data inthe data service backend storage system may also be stored inunencrypted form. In some embodiments, an API implemented by the dataservice frontend allows requests to specify whether data to be stored inthe data service backend storage system should be encrypted. Data thatis encrypted and stored in the data service backend storage system maybe encrypted in various ways in accordance with the various embodiments.For example, in various embodiments, data is encrypted using keysaccessible to the cryptography service, but inaccessible to some or allother systems of the environment 200. Data may be encoded by thecryptography service for storage in the data service backend storagesystem and/or, in some embodiments, data may be encrypted by anothersystem, such as a user system or a system of the data service frontend,using a key that was decrypted by the cryptography service. Examples ofvarious ways by which the environment 200 may operate to encrypt dataare provided below.

Numerous variations of the environment 200 (and other environmentsdescribed herein) are considered as being within the scope of thepresent disclosure. For example, the environment 200 may includeadditional services that may communicate with the cryptography serviceand/or authentication service. For example, the environment 200 mayinclude additional data storage services (which may each comprise afrontend system and a backend system) which may store data in differentways. For instance, one data storage service may provide active accessto data where the data storage service performs data storage services ina synchronous manner (e.g., a request to retrieve data may receive asynchronous response with the retrieved data). Another data storageservice may provide archival data storage services. Such an archivaldata storage service may utilize asynchronous request processing. Forexample, a request to retrieve data may not receive a synchronousresponse that includes the retrieved data. Rather, the archival datastorage service may require a second request to be submitted to obtainthe retrieved data once the archival data storage service is ready toprovide the retrieved data. As another example, the environment 200 mayinclude a metering service which receives information from thecryptography service (and/or other services) and uses that informationto produce accounting records. The accounting records may be used tobill customers for usage of the cryptography service (and/or otherservices). Further, information from the cryptography service mayprovide an indication of how charges should be incurred. For instance,in some instances customers may be provided bills for use of thecryptography service. In other instances, charges for use of thecryptography service may be rolled into usage charges of other services,such as a data service that utilizes the cryptography service as part ofits operations. Usage may be metered and billed in various ways, such asper operation, per period of time, and/or in other ways. Other dataservices may also be included in the environment 200 (or otherenvironments described herein).

In addition, FIG. 2 depicts users interacting with the data servicefrontend. It should be understood that users may interact with the dataservice frontend through user devices (e.g. computers) which are notillustrated in the figure. Further, the users depicted in FIG. 2 (andelsewhere in the figures) may also represent non-human entities. Forexample, automated processes executing on computer systems may interactwith the data service frontend as described herein. As one illustrativeexample, an entity represented by a user in FIG. 2 may be a server that,as part of its operations, uses the data service frontend to storeand/or retrieve data to/from the data service backend storage system. Asyet another example, an entity represented by a user in FIG. 2 may be anentity provided as a service of a computing resource provider thatoperates one or more of the services in FIG. 2. For instance, a user inFIG. 2 may represent a virtual or other computer system of a programexecution service offered by the computing resource provider. Othervariations, including variations of other environments described below,are also considered as being within the scope of the present disclosure.

For example, FIG. 3 shows an illustrative example of an environment 300in which various embodiments of the present disclosure may beimplemented. As with FIG. 2, the environment in FIG. 3 includes anauthentication service, a data service frontend system (data servicefront end), a cryptography service and a data service backend storagesystem. The authentication service, data service frontend, cryptographyservice and data service backend storage system may be configured suchas described above in connection with FIG. 2. For example, users mayaccess the data service frontend through a suitable communicationsnetwork, although such network is not illustrated in the figure. In theexample environment 300 illustrated in FIG. 3, arrows representing aflow of information are provided. In this example, a user transmits aPUT request to the data service frontend. The PUT request may be arequest to store specified data in the data service backend storagesystem. In response to the PUT request, the data service frontend maydetermine whether the PUT request is authentic, that is if the user hassubmitted the request in the manner the requested operation can beperformed in accordance with authentication policy implemented by thesystem.

In FIG. 3, an illustrative example of how such authentication decisionsmay be made is illustrated. In this particular example, the data servicefrontend submits an authentication request to the authenticationservice. The authentication service may use the authentication requestto determine if the PUT request from the user is authentic. If therequest is authentic, the authentication service may provideauthentication proof to the data service frontend. The authenticationproof may be an electronic token or other information that is usable byanother service, such as the cryptography service, to independentlydetermine that an authentic request was received. In one illustrativeexample, the PUT request is transmitted with a signature for the PUTrequest. The PUT request and its signature are provided through theauthentication service, which independently computes what a signatureshould be if authentic. If the signature generated by the authenticationservice matches that signature provided by the user, the authenticationservice may determine that the PUT request was authentic and may provideauthentication proof in response. Determining whether the PUT request isauthentic may also include one or more operations in connection with theenforcement of policy. For example, if the signature is valid but policyotherwise indicates that the PUT request should not be completed (e.g.the request was submitted during a time disallowed by policy), theauthentication service may provide information indicating that therequest is not authentic. (It should be noted, however, that such policyenforcement may be performed by other components of the environment300.) The authentication service may generate the signature, such as byusing a key shared by the authentication service and the user. Theauthentication proof, as noted, may be information from which anotherservice, such as the cryptography service, can independently verify thata request is authentic. For example, using the example of thecryptography service illustrated in FIG. 3, the authentication proof maybe generated based at least in part on a key shared by both theauthentication service and the cryptography service, such as a key thatis inaccessible to other services.

As illustrated in FIG. 3, the data service frontend, upon receipt ofauthentication proof from the authentication service, provides plaintextand authentication proof to the cryptography service. The plaintext andauthentication proof may be provided according to an API call or otherelectronic request to the cryptography service (e.g., an Encrypt APIcall). The cryptography service may analyze the authentication proof todetermine whether to encrypt the plaintext.

It should be noted that additional information may be provided to thecryptography service. For example, an identifier of a key to be used toencrypt the plaintext may be provided as an input parameter to the APIcall from the data service frontend (which, in turn, may have receivedthe identifier from the user). However, it should be noted that anidentifier may not be transmitted to the cryptography service. Forinstance, in various embodiments, it may be otherwise determinable whichkey to use to encrypt the plaintext. For example, informationtransmitted from the data service frontend to the cryptography servicemay include information associated with the user, such as an identifierof the user and/or an organization associated with the user, such as anidentifier of a customer on behalf of which the user has submitted thePUT request. Such information may be used by the cryptography service todetermine a default key to be used. In other words, the key may beimplicitly specified by information that is usable to determine the key.Generally, determination of the key to be used may be performed in anysuitable manner. Further, in some embodiments, the cryptography servicemay generate or select a key and provide an identifier of the generatedor selected key to be used later. Another example API parameter can bean identifier for a master key for the customer account the encryptionoperation is being performed for.

As illustrated in FIG. 3, if the authentication proof is sufficient tothe cryptography service for the plaintext to be encrypted, thecryptography service can perform one or more cryptographic operations.In an embodiment, the one or more cryptographic operations can includean operation to generate an envelope key to be used to encrypt theplaintext. The envelope key can be a randomly generated symmetric key ora private key of a key pair. After the envelope key is generated, thecryptographic service can encrypt the envelope key with the master keyspecified in the API call and cause the encrypted envelope key to bepersistently stored (e.g., by storing the encrypted key in a storageservice or some other durable storage) or discarded. In addition, thecryptographic service can send a plaintext version of the envelope keyas well as and the encrypted envelope key to the data service frontend.The data service can then use the plaintext version of the envelope keyto encrypt the plaintext (i.e., the data associated with the encryptionrequest) and cause the envelope key to be stored in persistent storagein association with an identifier for the master key used to encrypt theenvelope key. In addition, the data service can discard the plaintextversion of the envelope key. As such, in an embodiment after the dataservice discards the plaintext version of the envelope key it will nolonger be able to decrypt the ciphertext.

In an alternative embodiment, the cryptographic operation can involveencrypting the plaintext. For example, the cryptographic serviceencrypts the plaintext and provides ciphertext to the data servicefrontend storage system. The data service frontend may then provide theciphertext to the data service backend storage system for persistentstorage in accordance with its operation. Other information may also betransmitted from the data service frontend to the data service backendstorage system. For example, an identifier of the key used to encryptthe plaintext to generate ciphertext may be provided with the ciphertextfor storage by the data service backend storage system. Otherinformation, such as metadata identifying the user and/or the user'sorganization, may also be provided.

As with all environments described herein, numerous variations areconsidered as being within the scope of the present disclosure. Forexample, the flow of information among the various components of theenvironment 300 may vary from that which is shown. For example,information flowing from one component to another component through anintermediate component (e.g. data from the authentication service to thecryptography service and/or data from the cryptography service to thedata service backend storage system) may be provided directly to itsdestination and/or through other intermediate components of theenvironment 300 (which are not necessarily included in the figure). Asanother example, PUT requests (and, below, GET requests) are providedfor the purpose of illustration. However, any suitable request forperforming the operations described may be used.

FIG. 4 shows an illustrative example of a process 400 which may be usedto store data in a data storage service in accordance with anembodiment. The process 400 may be performed, for example, by the dataservice frontend illustrated in FIG. 3. Some or all of the process 400(or any other processes described herein, or variations and/orcombinations thereof) may be performed under the control of one or morecomputer systems configured with executable instructions and may beimplemented as code (e.g., executable instructions, one or more computerprograms or one or more applications) executing collectively on one ormore processors, by hardware or combinations thereof. The code may bestored on a computer-readable storage medium, for example, in the formof a computer program comprising a plurality of instructions executableby one or more processors. The computer-readable storage medium may benon-transitory.

As illustrated in FIG. 4, the process 400 includes receiving 402 a PUTrequest. The PUT request may be electronically received over a networkand may include information associated with the request, such asinformation required for authentication, such as an electronic signatureof the PUT request. In response to having received the PUT request, theprocess 400 may include submitting 404 an authentication request. Forexample, the system performed in the process 400 may submit (e.g., viaan appropriately configured API call) an authentication request to aseparate authentication service, such as described above in connectionwith FIG. 3. Similarly, a data service frontend that performs its ownauthentication may submit the authentication request to anauthentication module implemented by the data service frontend.Generally, the authentication request may be submitted in any suitablemanner in accordance with the various embodiments.

Upon submission of the authentication request, an authenticationresponse is received 406 by the entity to which the authenticationrequest was submitted 404. For example, referring to FIG. 3, theauthentication service may provide a response to the data servicefrontend that includes proof of the authentication for use by otherservices. Other information, such as an indication of whether or notauthentication was successful, may also be transmitted. A determinationmay be made 408 whether the request is authentic. Authenticity of therequest may depend from one or more factors checked by an entity, suchas by an authentication service, or a combination of entities thatcollectively perform such checks. Authenticity may, for example, requirethat the request provide necessary valid credentials (e.g., anelectronic signature generated by a secret key shared by the checkingentity) and/or that policy allows the request to be fulfilled. From theperspective of a system that submits 404 an authentication request andreceives an authentication response, authenticity may depend from thereceived authentication response. Accordingly, in an embodiment, thedetermination 408 whether the request is authentic may be performedbased at least in part of the received authentication response. Forexample, if authentication was not authentic, the authenticationresponse so indicates and the determination 408 may be made accordingly.Similarly, the response may implicitly indicate that the authenticationrequest is authentic, such as by not including information that would beincluded if the request was authentic. If it is determined 408 that thePUT request is not authentic, then the PUT request may be denied 410.Denying the PUT request may be performed in any suitable manner and maydepend upon the various embodiments in which the process 400 is beingperformed. For example, denying 410, the PUT request may includetransmitting a message to a user that submitted the PUT request. Themessage may indicate that the request was denied. Denying the requestmay also include providing information about why the request was denied,such as an electronic signature not being correct or other reasons thatmay be used for determining how to resolve any issues that resulted inthe PUT request not being authentic or authorized.

If it is determined 408 that the PUT request is authentic andauthorized, then, in an embodiment, the process 400 includes performing412 one or more cryptographic operations that result in the plaintextbeing encrypted. For example, a request (e.g., an appropriatelyconfigured API call) may be submitted to a cryptography service toprovide a key to be used for performing the one or more cryptographicoperations. The request provided to the cryptography service may beprovided with proof of the PUT request being authentic so that thecryptography service can independently determine whether to perform thecryptographic operation (e.g., to encrypt the plaintext and provideciphertext or generate an envelope key that can be used to encrypt theplaintext). However, in various embodiments, authentication proof maynot be provided to the cryptography service and, for example, thecryptography service may operate in accordance with the request that itreceives. For example, if the cryptography service receives a requestfrom the data service frontend, the cryptography service may rely on thefact that the data service frontend has already independently verifiedauthentication of the request. In such an embodiment and otherembodiments, the data service frontend may authenticate itself with thecryptography service to provide an additional layer of security. Thecryptography service may generate or otherwise obtain a key, encrypt theobtained key or otherwise obtain the encrypted key (e.g., from memory),and provide the obtained key and the encrypted obtained key in responseto the request. The obtained key may be encrypted using a key identifiedin the request to the cryptography service. The obtained key may be usedto encrypt the plaintext and, after encrypting the plaintext, theobtained key may be discarded (e.g., irrevocably removed from memory).In alternate embodiment, a system performing the process 400 maygenerate or otherwise obtain the key used to perform the one or morecryptographic operations, provide the obtained key to the cryptographyservice to be encrypted.

In some embodiments, performing the one or more cryptographic operationsmay result in ciphertext being generated. Ciphertext generated as aresult of one or more cryptographic operations may be stored 414 forpossible retrieval at a later time. As noted above, storage of theciphertext may include storage of additional information that wouldenable the decryption of the ciphertext at later time. For instance, theciphertext may be stored with an identifier of a key used to encrypt theplaintext into the ciphertext so that the key having that identifier maylater be used to decrypt the ciphertext to obtain the plaintext. Storageof the ciphertext may also be performed in any suitable manner. Forexample, storage of the ciphertext may be performed by a data servicebackend storage system, such as described above.

FIG. 5, accordingly, shows an illustrative example of an environment 500and the flow of information illustrating how plaintext may be obtained.The environment 500 in this example includes an authentication service,a cryptography service, a data service frontend and a data servicebackend storage system. The authentication service, cryptographyservice, data service frontend and a data service backend storage systemmay be systems such as described above. As illustrated in FIG. 5, thedata service frontend is configured to receive a GET request from a userand provide plaintext in response. In order to do this, the data servicefrontend may also be configured to submit authentication requests to anauthentication service which itself may be configured to, ifappropriate, provide to the data service frontend authentication proof.The data service frontend may also be configured to send a request tothe cryptographic service to cause it to execute one or morecryptographic operations related to decrypting the data. In anembodiment where envelope keys are used, the data service can submit arequest (e.g., an API call) to the cryptographic service that includesor specifies the encrypted envelope key (or an identifier for theencrypted envelope key) authentication proof, and an identifier of themaster key used to encrypt the envelope key to the cryptographicservice. The cryptographic service can determine whether theauthentication proof is sufficient to allow the operation and, if theauthentication proof is sufficient, decrypt the envelope key. Thedecrypted envelope key can be sent back to the data service, which canuse the key to decrypt the encrypted plaintext. The data service canthen discard the decrypted plaintext key.

In an alternative embodiment, the data service frontend may beconfigured to provide the received authentication proof to thecryptography service with ciphertext for the cryptography service todecrypt. The cryptography service may, accordingly, be configured todetermine whether the authentication proof is sufficient to allowdecryption of the ciphertext and, if the authentication proof issufficient, decrypt the ciphertext using an appropriate key (which maybe identified to the cryptography service by the data service frontend),and provide the decrypted ciphertext (plaintext) to the data servicefrontend. To provide ciphertext to the cryptography service, the dataservice frontend may be configured to obtain (e.g., via an appropriatelyconfigured API call) the ciphertext from the data service backendstorage system.

FIG. 6 shows an illustrative example of a process 600 which may be usedto obtain plaintext in accordance with various embodiments. The process600 may be performed, for example, by the data service frontend system(data service frontend) illustrated above in connection FIG. 5, althoughthe process 600 and variations thereof may be performed by any suitablesystem. In an embodiment, the process 600 includes receiving 602 a GETrequest (or other appropriate request) from a user. Receiving the GETrequest may be performed such as described above in connection withother types of requests. Upon receipt 602 of the GET request, anauthentication request may be submitted 604 to an authentication serviceor in any manner such as described above. An authentication responsemay, accordingly, be received. Based at least in part on the receiveauthentication response, a determination may be made 608 whether the GETrequest is authentic. If it is determined 608 that the GET request isnot authentic, the process 600 may include denying 610 the requestwhich, as described above, may be performed in various manners inaccordance with the various embodiments.

If it is determined 608 that the GET request is authentic, the process600 may include retrieving ciphertext from storage. Retrieving 612ciphertext from storage may be performed in any suitable manner. Forexample, referring to the environment 500 discussed above in connectionwith FIG. 5, the data service frontend may submit a request for theciphertext to the data service backend storage system and may receivethe ciphertext in response. Generally, ciphertext may be obtained fromstorage in any suitable manner. Upon receipt of the ciphertext, theprocess 600 may include performing 614 one or more operations relatingto decrypting the ciphertext. For example, in an embodiment, the datastorage service may send a request to the cryptographic service toperform one or more cryptographic operations relating to decrypting theciphertext 614. In one example configuration, the data service can sendthe cryptographic service an API call that includes the encryptedenvelope key (or an identifier for the encrypted envelope key)authentication proof, and an identifier of the master key used toencrypt the envelope key to the cryptographic service. The cryptographicservice can determine whether the authentication proof is sufficient toallow the operation and, if the authentication proof is sufficient,decrypt the envelope key. The decrypted envelope key can be sent back tothe data service, which can use the key to decrypt the encryptedplaintext.

In another configuration, the ciphertext may be provided to acryptography service such as the cryptography service described above inconnection with FIG. 5. Other information may also be provided to thecryptography service such as proof of authentication that can be used bythe cryptography service to determine whether or not to decrypt theciphertext. In addition, in some embodiments, an identifier of a key tobe used by the cryptography service to decrypt the ciphertext may beprovided to the cryptography service. However, in other embodiments, thekey may be implicitly indicated to the cryptography service. Forexample, the cryptography service may use a default key associated witha customer that is indicated to the cryptography service. Generally, anymanner by which the cryptography service can determine which key to useto decrypt the ciphertext may be used.

As illustrated in FIG. 6, after the ciphertext is decrypted, the process600 may include providing 616 a response to the GET request. Providing aresponse to the GET request may be performed in various ways inaccordance with the various embodiments. For example, providing theresponse to the GET request may include providing the plaintext. Inother embodiments, the plaintext may be a key that is used to decryptother encrypted information which is then provided in response to theGET request. Generally, depending on the role of the plaintext in aparticular embodiment of the disclosure, providing a response to the GETrequest may be performed in various ways.

As noted, various embodiments of the present disclosure allow for datato be stored by a data storage service in various ways. FIG. 7 shows anillustrative example of an environment 700 with arrows indicatinginformation flow in accordance with such embodiment. As illustrated inFIG. 7, environment 700 includes an authentication service, acryptography service, a data service frontend and a data service backendstorage system, such as described above. In this particular example, thedata service frontend is a computer system configured to receive PUTrequests from various users. PUT requests may include or specify dataobjects to be stored by a data service backend storage system. PUTrequests may also specify a key identifier for a key to be used toencrypt the data object. The data service frontend may also beconfigured to interact with an authentication service, such as describedabove, in order to provide authentication proof to a cryptographyservice that is operable to receive keys and key identifiers and providein response keys encrypted by the keys identified by the keyidentifiers. The data service frontend may then cause storage in a dataservice backend storage system. The data that may be stored may includea data object encrypted by the key. The data that may be stored may alsoinclude the key encrypted by the key identified by the key identifier.As discussed elsewhere, herein, the encrypted data object and encryptedkey may be stored in different services.

As illustrated in FIG. 7, the data service frontend is configured toprovide encrypted information to the data service backend storage systemfor storage. In this example, the data service frontend is configured toprovide a data object encrypted under a key and the key encrypted underanother key having a KeyID. It should be noted that, for the purpose ofillustration, curly bracket notation is used to denote encryption. Inparticular, information inside of curly brackets is the information thatis encrypted under a key specified in subscript. For example, {DataObject}_(Key) denotes that the data “Data Object” is encrypted under thekey “Key.” It should be noted that a key identifier may also appear insubscript using this curly bracket notation. When a key identifierappears in subscript, the information inside the curly brackets isencrypted under a key identified by the key identifier. For example,{Data Object}_(KeyID) denotes that the data object “Data Object” isencrypted under a key identified by the key identifier “KeyID.”Similarly, {Key}_(KeyID) denotes that the key “Key” is encrypted underthe key identified by the key identifier “KeyID.” In other words, thisdisclosure makes use of both keys and key identifiers in subscript andthe meaning of the subscript should be clear from context. Theciphertext may include additional metadata usable to determine theidentity of the associated decryption key.

FIG. 8 shows an illustrative example of a process 800 which may beperformed to store a data object in a data storage system, such as thedata service backend storage system described above in connection withFIG. 7. The process 800 may be performed by any suitable system, such asby the data service frontend system described above in connection withFIG. 7. In an embodiment, the process 800 includes receiving 802 a PUTrequest for a data object. Receiving the PUT request for the data objectmay be performed in any suitable manner, such as described above. Itshould be noted that the data object can be received in connection withthe request or may be received from another service. For example, therequest may include an identifier for a data object that may be obtainedfrom another service using the identifier. As with other processesdescribed above, the process 800 in an embodiment includes submitting804 an authentication request and receiving 806 an authenticationresponse. The authentication response that was received 806 may be usedto determine 808 whether the PUT request is an authentic request. If itis determined 808 that the PUT request is not authentic, the process 800may include denying 810 the request such as described above. If it isdetermined 808 that the PUT request is authentic, the process 800 mayinclude obtaining 812 a key identifier (KeyID), such as a keyID for amaster key used to encrypt envelope keys. Obtaining 812 the KeyID may beperformed in any suitable manner and the manner in which the KeyID isobtained may vary in accordance with the various embodiments. Forexample, as illustrated in FIG. 7, the PUT request may specify theKeyID. As another example, the identity of the user, or otherwiseassociated with the user, may be used to obtain an identifier or adefault key. As another example, the ciphertext may provide anindication of the associated key ID. As yet another example, one or morepolicy determinations may be used to determine which key identifier toobtain.

In an embodiment, the process 800 also includes generating 814 a key,such as an envelope key. Generating the key may be performed in anysuitable manner by, for example, the cryptographic service or theservice requesting encryption operations from the cryptographic service(e.g., a data storage service). For example, the key may be generatedusing a key derivation function using appropriate input to the keyderivation function. Example key derivation functions include KDF1,defined in IEEE Std 1363 2000, key derivation functions defined in ANSIX9.42, and HMAC-based key derivation functions, such as the HMAC-BasedExtract-and-Expand Key Derivation Function (HKDF) specified in RFC 5869.As another example, the key may be generated by a random or pseudorandom number generator, a hardware entropy source or a deterministicrandom bit generator such as is specified by National Institute ofStandards and Technology Special Publication (NIST SP) 800-90A. Itshould be noted that while FIG. 8 shows the process 800 includinggenerating 814 a key, the key may be obtained in other ways such as byretrieval from storage. In other words, the key may have beenpre-generated.

Continuing with the process 800 illustrated in FIG. 8, in an embodiment,the process 800 includes using 816 the generated key to encrypt a dataobject. For example, in an embodiment where the cryptographic servicegenerates the key, the cryptographic service can provide the key, theKeyID, and an encrypted copy of the key to the data service. Forexample, referring to FIG. 7, the data service frontend may receive theenvelope key and the KeyID for the master key used to encrypt theenvelope key from the cryptography service with any other relevantinformation, such as authentication proof. The plaintext copy of theencryption key may then be used to encrypt the data object. Theplaintext copy of the encryption key can be discarded and the encrypteddata object as well as the encrypted key may then be stored 818. Forexample, referring to FIG. 7, the data service frontend may transmit tothe encrypted data object and the encrypted key to the data servicebackend storage system for storage. In a configuration where the servicegenerates the key, the service can provide the key and the KeyID to thecryptography service. For example, the data service frontend may sendthe envelope key and the KeyID for the master key used to encrypt theenvelope key to the cryptography service with any other relevantinformation, such as authentication proof. The plaintext copy of theencryption key may then be used to encrypt the data object. The servicecan discard the plaintext copy of the encryption key and the encrypteddata object as well as the encrypted key may then be stored. Forexample, referring to FIG. 7, the data service frontend may transmit tothe encrypted data object and the encrypted key to the data servicebackend storage system for storage.

The encrypted data object and the encrypted envelope key may be storedwithout the plaintext version of key, that is, the plaintext key may beinaccessible to the data service backend storage system and one or moreother systems. The key under which the data object is encrypted (e.g.,the master key) may be made inaccessible in any suitable manner. In someembodiments this is achieved by storing it in memory accessible only tothe cryptographic service. In some other embodiments this can beachieved by storing the master key in a hardware or other securitymodule or otherwise under the protection of a hardware or other securitymodule. In some embodiments, the memory location storing the plaintextenvelope key (e.g., memory of the data service) may be allowed to beoverwritten or memory location storing the key may be intentionallyoverwritten to render inaccessible the key to the data service frontend.As another example, the plaintext envelope key may be maintained involatile memory that eventually ceases to store the key. In this manner,the envelope key is only accessible if it is decrypted using a keyidentified by the KeyID or otherwise obtained in an unauthorized manner,such as by cracking the key without the key identified by the KeyID,which may be computationally impractical. In other words, the keyidentified by the KeyID is required for authorized access to the keyunder which the data object is encrypted. Thus, if the data servicebackend storage system of FIG. 7 is compromised, such compromise wouldnot provide access to the unencrypted data object because decrypting thedata object would require access to the key, which is only obtainablethrough decryption using the key identified by the KeyID or throughother ways which are not computationally feasible.

As noted, various embodiments of the present disclosure allow users toboth store data objects and retrieve them in a secure manner. FIG. 9,accordingly, shows an illustrative example of an environment 900 whichmay be used to obtain data objects from storage. As illustrated in FIG.9, the environment 900 includes an authentication service, acryptography service, a data service frontend system and a data servicebackend storage system. The authentication service, cryptographyservice, data service frontend and data service backend storage systemmay be computer systems such as described above. As illustrated in FIG.9, the data service frontend system is configured to receive data objectrequests and provide data objects in response. In order to provide thedata objects in response, the data storage frontend system in thisembodiment is configured to interact with the authentication service,the cryptography service, and the data service backend storage system asillustrated in FIG. 9. For example, in various embodiments, the dataservice frontend system is configured to submit authentication requeststo the authentication service and receives authentication proof inresponse to the requests. As another example, the data service frontendis configured to provide keys encrypted by a key identified by a KeyIDand authentication proof to a cryptography service which is operable todetermine whether to provide the key based, at least in part, on theauthentication proof and, if determined to provide the key, then providethe key to the data service frontend. The data service frontend may alsobe configured to provide other information, such as the KeyID, to thecryptography service. Although, in some embodiments, the KeyID may beimplicitly indicated to the cryptography service, such as throughassociation with other information provided to the cryptography service.It should also be noted that, in some embodiments, the user provides theKeyID to the data service frontend in connection with submittingrequests to the data service frontend. Also, as illustrated in FIG. 9,the data service frontend in an embodiment is configured to request thedata object from the data service backend storage system and receive inresponse the data object encrypted by the key and the key encrypted by akey identified by the KeyID. In some embodiments the cryptographicservice may be operable to refuse to perform decryption of a ciphertextnot generated using a key associated with a specified KeyID.

The data service frontend, in an embodiment, is configured to use thekey received from the cryptography service to decrypt the data objectand provide the decrypted data object to the user. FIG. 10, accordingly,shows an illustrative example of a process 1000 which may be used toprovide the decrypted object in accordance with various embodiments. Theprocess 1000 may be performed by any suitable system such as the dataservice frontend system described in connection with FIG. 9. In anembodiment, the process 1000 includes receiving 1002 a GET request for adata object. Receiving the GET request for the data object may beperformed in any suitable manner such as described above in connectionwith other types of requests. For example, the GET request for the dataobject may include information used to authenticate the request and/orother information. The process 1000, accordingly, in an embodiment, aswith other processes described herein, includes submitting 1004 anauthentication request to an authentication system and receiving 1006 anauthentication response. Submitting the authentication request andreceiving the authentication response may be performed in any suitablemanner, such as described above. The authentication response may be usedto determine 1008 whether or not the GET request is authentic. If it isdetermined 1008 that the GET request is not authentic, the process 1000in an embodiment includes denying 1010 the request. If, however, it isdetermined 1008 that the GET request is authentic, the process 1000 inan embodiment includes retrieving 1012 the encrypted data object and anencrypted key from storage. For example, the data service frontendsystem may obtain the encrypted data object and encrypted key from thedata service backend storage system illustrated above in connection withFIG. 9.

In an embodiment, the process 1000 includes providing 1014 the encryptedenvelope key to a cryptography service. Providing 1014 the encryptedenvelope key to the cryptography service may be performed in anysuitable manner and may be provided with other information, such asauthentication proof that enables the cryptography service to determinewhether to decrypt the encrypted key. In addition, providing 1014 theencrypted envelope key to the cryptography service may include providingan identifier of a key required for authorized decryption of theencrypted envelope key to enable the cryptography service to select akey identified by the identifier from among multiple keys managed by thecryptography service. As noted above, however, keys may be implicitlyidentified. The cryptography service may, accordingly, select anappropriate key and decrypt the encrypted key. Accordingly, in anembodiment, the process 1000 includes receiving 1016 the decryptedenvelope key from the cryptography service. For example, if thecryptography service determines that the authentication proof is validand/or that decryption of the encrypted is allowable according to anyapplicable policies, the cryptography service may provide the decryptedkey to a system attempting to decrypt the data object. The data objectmay then be decrypted 1018 using the decrypted envelope key. Thedecrypted data object may then be provided 1020 to the requestor, suchas the user or other system that submitted the GET request.

In many instances, it is desirable for users (i.e., generally devicesutilizing a cryptography service) to interact directly with thecryptography service. FIG. 11 accordingly shows an illustrative exampleof an environment 1100 which allows for direct user access to acryptography service. In environment 1100, included is an authenticationservice, a data service frontend and a data service backend storagesystem. The authentication service, data service frontend and dataservice backend storage system may be as described above. For example,the data service frontend may be configured to receive and respond torequests from users as illustrated in FIG. 11 over a suitable network.As part of responding to requests from the users over the network, thedata service frontend may also be configured to interact with theauthentication service in order to determine whether user requests areauthentic and/or enforce policy on the requests. The data servicefrontend may also be configured to interact with the data servicebackend storage system as part of fulfilling user requests. Userrequests may include, for example, PUT requests to store data in thebackend storage system and GET requests to retrieve data from the dataservice backend storage system. As above, other requests may also beused in accordance with the various embodiments, such as requests todelete data stored in the data service backend storage system, requeststo update the data stored in the data service backend storage system andthe like.

In the particular example of FIG. 11, in the environment 1100, thecryptography service includes a cryptography service frontend and a dataservice backend. As with the data service frontend, the cryptographyservice frontend is configured to receive and respond to requests fromusers over the network. The cryptography service frontend is alsoconfigured to interact with the authentication service to determinewhether user requests are authentic. Determining whether user requestsare authentic may be performed in a simple manner such as describedabove. It should be noted that, while the cryptography service frontendand the data service frontend interact with the same authenticationservice, the cryptography service frontend and the data service frontendmay interact with different authentication services. Further, thecryptography service frontend may be configured to enforce policy whenresponding to user requests.

The cryptography service frontend, in an embodiment, is configured tointeract with the cryptography service backend. The cryptography servicebackend is configured, in accordance with instructions received from thecryptography service frontend, to perform cryptographic operations.Cryptographic operations include encryption, decryption and hashcalculations and others. The environment 1100 may be used, for example,by users to have plaintext encrypted by the cryptography service so thatthe encrypted data can be stored in the data service backend storagesystem. Examples of such use of the environment 1100 are provided below.In addition, example details of an example cryptography service are alsoprovided below.

Data may be stored in the data service backend storage system in anysuitable manner such as described above. For example, techniques forstoring encrypted data in the backend storage system described above maybe used in the environment 1100. For example, while not illustrated, thedata service frontend may communicate with the cryptography servicefrontend to cause the cryptography service backend to encrypt data whichmay then be stored in the data service backend storage system. Theencrypted data may be a data object and/or an encrypted key that wasused to encrypt a data object. In the environment 1100, data may beplaced into the data service backend storage system in other ways aswell. For example, users may provide plaintext to be encrypted by thecryptography service and may receive ciphertext in response. The usersmay then interact or may submit a request to the data service frontendto request that the ciphertext be stored in the data service backendstorage system. The data service frontend, in this example, may storethe ciphertext in any manner. For instance, the data service frontendand backend storage systems may be configured to be indifferent towhether data is encrypted.

In addition, as with all environments illustrated herein, an additionalfrontend system may be logically located between the users and the dataservice frontend and the cryptography service frontend and possiblyother frontend systems in order to coordinate actions between thesystems. For example, in some embodiments, users may interact with afrontend system that itself interacts with the cryptography servicefrontend and data service frontend so that operations from theperspective of the user are simpler. For example, a user may requestthat a data object be encrypted and stored and a frontend systemresponds to the request by appropriate interactions with thecryptography service frontend and data service frontend. From theperspective of the user, however, such may be performed by a singlerequest. Other variations are also within the scope of the presentdisclosure.

FIG. 12 shows an illustrative example of an environment 1200 which maybe used to implement various embodiments of the present disclosure. InFIG. 12, the environment 1200 is configured to enable users to storeciphertext in a data service backend storage system. As illustrated inFIG. 12, accordingly, the environment 1200 includes a data servicefrontend, a data service backend storage system, an authenticationservice, a cryptography service frontend and a cryptography servicebackend. The data service backend storage system, the data servicefrontend, the authentication service, the cryptography service frontendand the cryptography service backend may be systems such as describedabove in connection with FIG. 11. For example, as illustrated in FIG.12, the data service frontend is configured to receive and respond touser requests and may also be configured to enforce policy on userrequests. The data service frontend, as part of responding to requests,may be configured to submit authentication requests to theauthentication service and receive authentication proof in response inresponse. Upon successful authentication, the data service frontend maybe further configured to interact with the data service backend storagesystem to obtain encrypted data objects and possibly unencrypted dataobjects from the data service backend storage system, which may be thenprovided to a user.

As illustrated in FIG. 12, the cryptography service frontend is alsoconfigured to submit authentication requests to the authenticationservice and receive, in response, authentication proof. Authenticationproof may be used to obtain services from the cryptography servicebackend. For example, the cryptography service frontend may beconfigured to provide ciphertext to the cryptography service backendwith authentication proof and the cryptography service backend may beconfigured to decrypt the ciphertext and provide the ciphertext inreturn. As illustrated in FIG. 12, the ciphertext may be an encryptedkey and the cryptography service backend may decrypt the encrypted keyand provide the decrypted key, that is a plaintext key, to thecryptography service frontend, which is further configured to providethe plaintext key to the user. The user may then use the key to decryptthe encrypted data object received from the data service frontend or todecrypt encrypted data objects stored within the user's domain (e.g.,within a user operated or controlled data center or computer system). Inthis example, the user may have obtained the encrypted key from the dataservice frontend. For example, the user may have submitted a request tothe data service frontend for the data object and/or the key used toencrypt the data object. While illustrated in FIG. 11 as a singlerequest, the separate requests may be made for both the data object andthe key. As illustrated in FIG. 11, the data service frontend may obtainthe encrypted data object and encrypted key from the data servicebackend storage system and provide the encrypted data object andencrypted key to the user.

It should be noted that, as with all environments illustrated herein,variations are considered as being within the scope of the presentdisclosure. For example, FIG. 12 shows a data object encrypted under akey and the key encrypted by another key identified by a key identifierbeing provided to the user. Further levels of encryption may also beused. For example, the data object may be encrypted under a key that isonly accessible to the user (and/or that is not accessible by the othercomponents of the environment 1200). A key used to encrypt the dataobject may also be encrypted under the key that is only accessible tothe user. In this example, unauthorized access to the components of theenvironment 1200 (absent the user) still does not provide access to theunencrypted contents of the data object since access to the user's keyis still required for authorized decryption.

As another example, in the environment 1200 illustrated in FIG. 12, thedata service frontend and the data service backend storage system do nothave access to the plaintext data stored by the data service backendstorage system because the data service frontend and the data servicebackend storage system do not have access to a key needed to decrypt theencrypted data. In some embodiments, however, access may be granted tothe data service frontend and/or the data service backend storagesystem. For instance, in an embodiment, temporary access to the key maybe provided to the data service frontend to enable the data servicefrontend to obtain encrypted data, decrypt the encrypted data, use thedecrypted data for a particular purpose (e.g., indexing), and thendelete or otherwise lose access to the decrypted data. Such actions maybe governed by policy enforced by the data service frontend and/orcryptography service and may require authorization from the user.

FIG. 13 shows an illustrative example of a process 1300 which may beused to obtain an encrypted data object and an encrypted key such asfrom a data service backend storage system such as described above. Theprocess 1300, for example, may be performed by the data service frontendsystem described above in connection with FIG. 12. In an embodiment, theprocess 1300 includes receiving 1302 a GET request for an encrypted dataobject. Receiving the GET request may be performed in any suitablemanner such as by receiving the request via an API call to the dataservice frontend system. As a result of having received the GET request,process 1300 may include submitting 1304 an authentication request andreceiving 1306 an authentication response. Submitting 1304 theauthentication request and receiving 1306 the authentication responsemay be performed in any suitable manner such as described above. Theauthentication response may be used to determine 1308 whether the GETrequest is authentic. If it is determined 1308 that the GET request isnot authentic, the process 1300 may include denying 1310 the GETrequest. Denying 1310 the GET request may be performed in any suitablemanner such as described above. If, however, it is determined 1308 thatthat GET request is authentic, the process 1300 may include providing1312 the encrypted data object with an encrypted key that, whendecrypted, is usable to decrypt the encrypted data object. It should benoted that, as with all processes described herein, numerous variationsare considered as being within the scope of the present disclosure. Forexample, the process 1300 may be configured to respond to the GETrequest, when authentic, by providing the encrypted data object butwithout providing an encrypted key. A requester, that is a user orsystem that submitted the GET request, may obtain the encrypted key inother ways. For example, in some embodiments, users may store encryptedkeys themselves in a data storage system under the user's control. Asanother example, one storage service may store the encrypted data objectand another service may store the encrypted key and the user may obtainthe encrypted data object and encrypted key from the respectiveservices. As another example, another service or a third party to theuser may be used to store encrypted keys and users may obtain encryptedkeys upon request. Generally, any way by which encrypted keys may beprovided may be used.

As illustrated in FIG. 13, the process 1300 may result in an entityhaving been provided a data object and an encrypted key usable todecrypt the data object. In various embodiments, the encrypted key mustbe decrypted in order to decrypt the data object. FIG. 14, accordingly,shows an illustrative example of a process 1400 which may be used toprovide a decrypted key to an entity in need of such a decrypted key inorder to use the decrypted key for decryption of an encrypted dataobject. The process 1400 may be performed by any suitable system such asby the cryptography service frontend system described above inconnection with FIG. 12. In an embodiment, the process 1400 includesreceiving 1402 a decryption to decrypt a key using another key having aspecified KeyID. While the process 1400 is described in connection withdecryption of a key, it should be noted that the process 1400 may beadapted for decryption of data in general. The decryption request may bereceived 1402 in any suitable manner such as described above (e.g., viaan appropriately configured API call). Further, the decryption requestmay be received by any entity appropriate to the context in which theprocess 1400 is being performed. For instance, the decryption requestmay originate from the user or from another system, such as the dataservice frontend discussed above. The decryption request may alsoinclude data (e.g. a key) to be decrypted or a reference thereto. TheKeyID may be specified also in any suitable manner. For example, in someembodiments, the decryption request includes the KeyID or a reference tothe KeyID, that is, information that can be used to determine the KeyID.As discussed above, the KeyID may also be implicitly specified. Forexample, the KeyID may be obtained through association with availabledata such as an identity of a requester that submitted the decryptionrequest. For instance, the key corresponding to the KeyID may be adefault key for the requestor or for the entity on behalf of which therequest was submitted.

The process 1400, in an embodiment, includes submitting 1404 anauthentication request and receiving 1406 an authentication response.Submitting 1404 the authentication request and receiving 1406 theauthentication response may be performed in any suitable manner such asdescribed above. Further, as described above, the receivedauthentication response may be used to determine 1408 whether the GETrequest is authentic. If it is determined 1408 that the GET request isnot authentic, the process 1400 may include denying 1410 the GETrequest. Denying 1410 the GET request may be performed in any suitablemanner such as is described above. If, however, it is determined 1408that the GET request is authentic, the process 1400 may includeaccessing policy information for the specified KeyID and/or for therequester. Policy information may include information including one ormore policies on the KeyID and/or the requester.

In an embodiment, the accessed policy information is used to determine1414 whether any applicable policy allows decryption of the key havingthe specified KeyID. If it is determined 1414 that the policy does notallow decryption of the key specified by the KeyID, the process 1400 mayinclude denying 1410 the GET request such as described above. If,however, it is determined 1414 that policy allows decryption of the keyhaving the specified KeyID, the process 1400 may include decrypting 1416the key using the key identified by the KeyID. Once the key has beendecrypted, using a key having the KeyID, the decrypted key may then beprovided 1418 such as by transmission over a network to the requesterthat submitted the decryption request (or, in some embodiments, anotherauthorized destination).

As illustrated in the environment 1200 discussed above, a user mayobtain encrypted data objects and keys for decrypting the data objectsin various ways. FIG. 15 shows an illustrative example of a process 1500which may be used to obtain plaintext in accordance with variousembodiments. The process 1500 may be performed by any suitable systemsuch as by a system being operated and/or hosted by a user such asdescribed in connection with FIG. 12. Other suitable systems includesystems operating on behalf of users and not necessarily according toreal time user input provided but perhaps according to preprogrammedprocesses.

In an embodiment, the process 1500 includes receiving 1502 ciphertextfrom a data storage service. Requesting 1502 ciphertext from a datastorage service may be performed in any suitable manner such asdescribed above. For example, a system performing the process 1500 mayrequest 1502 ciphertext, using an appropriately configured API call inthe environment 1200 illustrated above in connection with FIG. 12 and/orby the process 1300 described above in connection with FIG. 13.

The process 1500 may also include receiving ciphertext and an encryptedkey. Receiving ciphertext and encrypted key may be performed in anysuitable manner. For example, the ciphertext and encrypted key may bereceived in a response to the request for the ciphertext from a datastorage service. Generally, however, the ciphertext and encrypted keymay be received 1504 in other suitable ways. For example, the request toreceive ciphertext from the data storage service may be an asynchronousrequest and ciphertext may be received 1504 pursuant to another requestthat is subsequently submitted. Further, the ciphertext and encryptedkey may be provided in a single response or may be obtained separatelysuch as by different responses (which may be from the same or fromdifferent systems). As another example, a system performing a process1500 may locally or otherwise store encrypted keys and the encrypted keymay be received from local memory.

In an embodiment, the process 1500 includes requesting decryption of theencrypted key, using a key having a specified KeyID. The KeyID may bespecified in any suitable manner such as described above. Further, itshould be noted that the system performing the process 1500 may be ableto specify the KeyID in any suitable manner. For example, the encryptedkey and/or information provided therewith may specify the KeyID. Asanother example, the system performing the process 1500 may have localor remote access to information that enables determining the KeyID. Alocal or remote database, for instance, may associate data objectidentifiers with key identifiers for keys used to encrypt the dataobjects. Generally, any manner in which the system can be enabled tospecify the KeyID may be used. Further, in some embodiments, the KeyIDneed not be specified, such as when information provided to acryptography service is sufficient to determine the KeyID. The request1506 for decryption of the encrypted key may be performed in anysuitable manner such as in connection with an environment discussedabove in connection with FIG. 12 and/or by performance of the process1400 described above in connection with FIG. 14.

The process 1500, in an embodiment, includes receiving 1508 thedecrypted key. Receiving 1508 the decrypted key may be performed in anysuitable manner. For example, the decrypted key may be received inresponse to a request for decryption of the encrypted key. As anotherexample, the request for decryption of the encrypted key may be anasynchronous request and another request may have been submitted forreceiving the decrypted key. Generally, the decrypted key may bereceived in any suitable manner. Further, as with all informationflowing from one device to another, the passage of information may beperformed using secure channels. For instance, the decrypted key may beonce again encrypted for decryption by an entity receiving the decryptedkey. Generally, any manner of secure communication may be used to passinformation from one entity to another.

Once the decrypted key has been received 1508, the process 1500 mayinclude using 1510 the decrypted key to decrypt 1510 ciphertext andtherefore obtain plaintext. It should be noted that, as with allprocesses described herein, variations are considered as being withinthe scope of the present disclosure. For example, the process 1500 showsa request for ciphertext and a request for decryption of an encryptedkey being performed sequentially. However, as with many operationsdescribed herein in connection with the various processes, operationsneed not be performed sequentially in various embodiments. For example,if a system performing the process 1500 has access to the encrypted keyprior to requesting the ciphertext, or is otherwise able to do so, thesystem may request ciphertext and request decryption of the encryptedkey in parallel or in an order different from that which is illustrated.Other variations are also considered as being within the scope of thepresent disclosure.

As discussed above, various embodiments of the present disclosure aredirected to providing cryptography services. Cryptography services maybe provided by a cryptography service system such as described above.FIG. 16 accordingly shows an illustrative example of a cryptographyservice 1600 in accordance with various embodiments. As illustrated inFIG. 16 and as discussed above, the cryptography service 1600 islogically comprised of a frontend system and a backend system. Both thefrontend system and the backend system may be implemented by one or morecomputer systems configured to perform operations described herein. Forexample, as illustrated in FIG. 16, the frontend system of thecryptography service 1600 implements a request API and a policyconfiguration API. The request API, in an embodiment, is an APIconfigured for requesting cryptographic and other operations to beperformed by the cryptography service. Thus, requests may be made to thefrontend system via the request API in order for such cryptographicoperations to be performed by the cryptography service.

The request API may be configured with the following example,high-level, requests available:

CreateKey(KeyID)

Encrypt(KeyID, Data, [AAD])

Decrypt(KeyID, Ciphertext, [AAD])

Shred(KeyID)

ReKey(Ciphertext, OldKeyID, NewKeyID).

A CreateKey(KeyID) request, in an embodiment, causes the cryptographyservice to create a key identified by the KeyID identified in therequest. Upon receipt of a request, the cryptography service maygenerate a key and associate the key with the KeyID. It should be knownthat KeyID's may be, but are not necessarily unique identifiers. Forinstance, a KeyID may identify a family of keys. For example, in someembodiments, key rotation is performed. Key rotation may involvereplacing keys with other keys to prevent collection of enough decrypteddata to allow practical cracking of a cipher used. If performed at thedirection of an entity different from the cryptography service, use ofthe CreateKey(KeyID) request may cause the cryptography service tocreate a new key to replace an old key identified by the KeyID. The oldkey may remain identified by the KeyID, but may, for instance, be onlyused for decryption (of data that has already been encrypted using theold key) and not for future encryption. As another example, in someembodiments, users of the cryptography service provide their own keyidentifiers and there is a possibility that two different customers mayprovide the same identifier. In such instances, the identifier may notuniquely identify a key or even uniquely identify a family of keys.Various measures may be in place to address this. For example, anidentity or other information associated with a user of the cryptographyservice may be used to identify the proper key or family of keys. Instill other embodiments the cryptographic service may assign a KeyIDrandomly, sequentially, or using any other method.

It should be noted that, when a KeyID does not uniquely identify a key,various systems may be in place to enable proper functionality. Forexample, in various embodiments, a family of keys identified by a KeyIDis finite. If a decryption operation using a key identified by a KeyIDis requested, additional data (e.g., a time stamp of when the encryptionwas performed) may enable determining the proper key to use. In someembodiments, ciphertexts may include information indicating a keyversion. In some embodiments, all possible keys are used to providedifferent decryptions of the data. Since there are a finite number ofkeys, the proper decryption may be selected from those provided. In someembodiments, decryption with a key is performed in a manner that enablesthe cryptographic service to detect that the ciphertext was notgenerated based at least in part on the key, such as by usingauthenticated encryption. Other variations are also considered as beingwithin the scope of the present disclosure.

An Encrypt(KeyID, Data, [AAD]) request may be used to cause thecryptography service to encrypt the specified data using a keyidentified by the KeyID. Additional Authenticated Data (AAD) may be usedfor various purposes and may be data that is not necessarily encrypted,but that is authenticated, e.g. by an electronic signature, a messageauthentication code or, generally, a keyed hash value included with theAAD. In some embodiments, the ciphertext is generated including at leasta portion of the AAD. In some other embodiments the AAD is providedseparately during decryption. In some other embodiments, the AAD isgenerated at decryption time based at least in part on the request andor other metadata such that decryption will only succeed when themetadata passes. In some embodiments, policy may constrain whether acryptographic operation can be performed with respect to particular AAD.Processing of Encrypt(KeyID, Data, [AAD]) requests may require, byprogramming logic and/or policy enforced by the cryptography service,both that the AAD contain particular values and that the AAD beauthentic (e.g., not modified since original transmission). Similarly, aDecrypt(KeyID, Ciphertext, [AAD]) request may be used to cause thecryptography service to decrypt the specified ciphertext using a keyidentified by the KeyID. The AAD in the Decrypt(KeyID, Ciphertext,[AAD]) request may be used such as described above. For instance,processing of the Decrypt(KeyID, Ciphertext, [AAD]) may require, byprogramming logic and/or policy enforced by the cryptography service,both that the AAD contain particular values and that the AAD beauthentic (e.g., not modified since original transmission).

The Shred(KeyID), in an embodiment, may be used to cause thecryptography service to electronically shred a key or family of keysidentified by the specified KeyID. Electronic shredding may includemaking the key no longer accessible. For example, use of theShred(KeyID) request may cause the cryptography system to command one ormore hardware devices to perform a SecureErase operation on one or morekeys identified by the specified KeyID. Generally, the key(s) identifiedby the KeyID may be electronically shredded in any suitable manner, suchas by overwriting data encoding the key with other data (e.g., a seriesof zeros or ones or a random string). If the key(s) are stored encryptedunder a key, the key used to encrypt the keys may be electronicallyshredded, thereby causing a loss of access to the key(s). In someembodiments, the shred operation may cause decrypt operations indicatingthe shredded KeyID to fail at some determined point in the future. Othermanners of securely and permanently destroying any possible access tothe key(s) may be used.

The ReKey(Ciphertext, OldKeyID, NewKeyID) request, in an embodiment, maybe used to cause the cryptography service to encrypt ciphertext under adifferent key. When the cryptography service receives aReKey(Ciphertext, OldKeyID, NewKeyID) request, it may use a keyidentified by the OldKeyID to decrypt the specified ciphertext and thenuse a key identified by the NewKeyID to encrypt the decryptedciphertext. If a key identified by the NewKeyID does not yet exist, thecryptography service may generate a key to use and associate thegenerated key with the specified NewKeyID, such as described inconnection the Create(KeyID) request described above. In someembodiments, the ReKey operation may be operable to cause data to betransferrable between isolated instances of a cryptography service. Insome embodiments, a policy might permit a rekey operation to beperformed on a ciphertext but might not permit the same requestor todirectly decrypt the ciphertext. In some embodiments, ReKey mightsupport rekeying a ciphertext from a key identified by a first KeyIDwithin a first account to a key identified by a KeyID within a secondaccount.

Similarly, the frontend system may implement a policy configuration APIwhich, in an embodiment, enables users to submit requests forconfiguring policies for the performance of cryptographic operations andfor other policy-related operations. Policies may be associated withkeys, groups of keys, accounts, users and other logical entities invarious embodiments. Example policies, which may be configured via thepolicy configuration API, are provided below. In an embodiment, thecryptography service policy configuration API includes the followingrequests:

SetKeyPolicy(KeyID, Policy)

Suspend(KeyID, Public Key)

Reinstate(KeyID, Private Key)

In an embodiment, the SetKeyPolicy(KeyID, Policy) request may be used tocause the cryptography service to store a policy on the key (or familyof keys) identified by the KeyID. A policy may be information that isdeterminative of whether a requested cryptographic operation can beperformed in a particular context. The policy may be encoded in adeclarative access control policy language, such as eXtensinble AccessControl Markup Language (XACML), Enterprise Privacy AuthorizationLanguage (EPAL), Amazon Web Services Access Policy Language, MicrosoftSecPol or any suitable way of encoding one or more conditions that mustbe satisfied for a cryptographic operation to be performed. Policies maydefine what operations can be performed, when the operations can beperformed, which entities can make authorized requests for operations tobe performed, which information is required for a particular request tobe authorized, and the like. In addition, policies may be defined and/orenforced using access control lists, privileges associated with users,and/or operation bitmasks in addition to or instead of the examplesgiven above. Example policies appear below.

In some embodiments the cryptographic service may support a suspendoperation, e.g., using a Suspend(KeyID, Public Key) API call. A suspendoperation enables the customer of the cryptographic service to deny theoperator of the cryptographic service use of or access to a key. Thiscan be useful to customers concerned about covert lawful orders or othercircumstances in which the operator of the cryptographic service mightbe compelled to perform some operation using a key. It may also beuseful to customers that wish to lock particular data and render itinaccessible online. In some embodiments, a suspend operation mightinclude receiving a public key from a customer and encrypting the keyspecified by a given KeyID with the received public key and shreddingthe key specified by the KeyID, such that the provider is not able toaccess the suspended key unless the private key associated with thepublic key is provided, e.g., using a Reinstate(KeyID, Private Key) APICall that both specifies the KeyID and includes the private key. In someother embodiments, a suspend operation might involve encrypting a keyassociated with a specified KeyID using another key managed by thecryptographic service, including without limitation one created for thepurpose of the instant suspend operation. The ciphertext produced bythis operation can be provided to the customer and not retained withinthe cryptographic service. The original key identified by the KeyID canthen be shredded. The cryptographic service may be operable to receivethe provided cipertext and re-import the suspended key. In someembodiments the ciphertext may be generated in a manner that willprevent the cryptographic service from returning a decrypted version tothe customer.

As illustrated in FIG. 16, the cryptography service 1600 includes abackend system that itself comprises various components in someembodiments. For example, the backend system in this example includes arequest processing system which may be a subsystem of the cryptographyservice 1600 that is configured to perform operations in accordance withrequests received through either the request API or the policyconfiguration API. For example, the request processing component mayreceive requests received via the request API and the policyconfiguration API determines whether such requests are authentic and aretherefore fulfillable and may fulfill the requests. Fulfilling therequest may include, for example, performing and/or having performedcryptographic operations. The request processing unit may be configuredto interact with an authentication interface which enables the requestprocessing unit to determine whether requests are authentic. Theauthentication interface may be configured to interact with anauthentication system such as described above. For example, when arequest is received by the request processing unit, the requestprocessing unit may utilize the authentication interface to interactwith an authentication service which may, if applicable, provideauthentication proof that may be used in order to cause a performance ofcryptographic operations.

The backend system of the cryptography service 1600 also, in thisillustrative example, includes a plurality of a security modules(cryptography modules) and a policy enforcement module. One or more ofthe security modules may be hardware security modules although, invarious embodiments, a security module may be any suitable computerdevice configured according to have capabilities described herein. Eachsecurity module in an embodiment stores a plurality of keys associatedwith KeyIDs. Each security module may be configured to securely storethe keys so as to not be accessible by other components of thecryptography service 1600 and/or other components of other systems. Inan embodiment, some or all of the security modules are compliant with atleast one security standard. For example, in some embodiments, thesecurity modules are each validated as compliant with a FederalInformation Processing Standard (FIPS) outlined in FIPS Publication140-1 and/or 140-2, such as one or more security levels outlined in FIPSPublication 140-2. In addition, in some embodiments, each securitymodule is certified under the Cryptogrpahic Module Validation Program(CMVP). A security module may be implemented as a hardware securitymodule (HSM) or another security module having some or all capabilitiesof an HSM. In some embodiments, a validated module is used to bootstrapoperations. In some embodiments, customers can configure some keys thatare stored in and operated on only by validated modules and other keysthat are operated on by software. In some embodiments, the performanceor cost associated with these various options may differ.

The security modules may be configured to perform cryptographicoperations in accordance with instructions provided by the requestprocessing unit. For example, the request processing unit may provideciphertext and a KeyID to an appropriate security module withinstructions to the security module to use a key associated with theKeyID to decrypt the ciphertext and provide in response the plaintext.In an embodiment, the backend system of the cryptography service 1600securely stores a plurality of keys forming a key space. Each of thesecurity modules may store all keys in the key space; however,variations are considered as being within the scope of the presentdisclosure. For example, each of the security modules may store asubspace of the key space. Subspaces of the key space stored by securitymodules may overlap so that the keys are redundantly stored throughoutthe security modules. In some embodiments, certain keys may be storedonly in specified geographic regions. In some embodiments, certain keysmay be accessible only to operators having a particular certification orclearance level. In some embodiments certain keys may be stored in andused only with a module operated by a particular third party providerunder contract with the provider of data storage services. In someembodiments, constructive control of security modules may require thatlawful orders seeking to compel use of keys other than as authorized bythe customer to involve either additional entities being compelled oradditional jurisdictions compelling action. In some embodiments,customers may be offered independent options for the jurisdiction inwhich their ciphertexts are stored and their keys are stored. In someembodiments, security modules storing keys may be configured to provideaudit information to the owner of the keys, and the security modules maybe configured such that the generation and providing of auditinformation not suppressible by the customer. In some embodiments, thesecurity modules may be configured to independently validate a signaturegenerated by the customer such that the provider (e.g., hosting thesecurity modules) is not able to perform operations under keys stored bythe security modules. In addition, some security models may store all ofthe key space and some security modules may store subspaces of the keyspace. Other variations are also considered as being the scope of thepresent disclosure. In instances where different security modules storedifferent subspaces of the key space, the request processing unit may beconfigured such as with a relational table or other mechanism todetermine which security module to instruct to perform cryptographicoperations in accordance with various requests.

In an embodiment, the policy enforcement module is configured to obtaininformation from a request processing unit and determine, based at leastin part on that information, whether the request received through theAPI may be performed. For example, when a request to performcryptographic operation is received through the request API, the requestprocessing unit may interact with the policy enforcement module todetermine whether fulfillment of the request is authorized according toany applicable policy such as policy applicable to a specified KeyID inthe request and/or other policies such as policy associated with therequestor. If the policy enforcement module allows fulfillment of therequest, the request processing unit may, accordingly, instruct anappropriate security module to perform cryptographic operations inaccordance with fulfilling the request.

As with all figures described herein, numerous variations are consideredas being within the scope of the present disclosure. For example, FIG.16 shows the policy enforcement module separate from security modules.However, each security module may include a policy enforcement module inaddition to or instead of the policy enforcement module illustrated asseparate. Thus, each security module may be independently configured toenforce policy. In addition, as another example, each security modulemay include a policy enforcement module which enforces policiesdifferent from policies enforced by a separate policy enforcementmodule. Numerous other variations are considered as being within thescope of the present disclosure.

As discussed above, various policies may be configured by users in orassociation with KeyID such that when requests specify cryptographicoperations being performed in connection with keys corresponding toKeyIDs, policy may be enforced. FIG. 17 provides an illustrative exampleof the process 1700 for updating policy in accordance with variousembodiments. Process 1700 may be performed by any suitable system, suchas by a cryptography service system, such as described above inconnection with FIG. 16. In an embodiment, the process 1300 includesreceiving 1302 a request to update policy for a KeyID. The request maybe received 1302 in any suitable manner. For example, referring to FIG.16 as an example, a request may be received through a policyconfiguration API of the frontend system of the cryptography service1600 described above. The request may be received in any suitablemanner.

The process 1700 in an embodiment includes submitting 1704 anauthentication request and receiving 1706 an authentication response.Submitting 1704 the authentication request and receiving 1706 theauthentication response may be performed in any suitable manner such asdescribed above. Also as described above, the received authenticationresponse may be used to determine 1708 whether the request to updatepolicy for the KeyID is authentic. If it is determined 1708 that thereceived request to update policy for the KeyID is not authentic, therequest may be denied 1710. Denying 1710 the request may be performed inany suitable manner as described above. If, however, it is determined1708 that the received request to update policy for the KeyID isauthentic, the process 1700 may include accessing 1712 policyinformation applicable to the requestor. The policy information may beinformation from which any policy applicable to the requestor may beenforced. For example, within an organization that utilizes acryptography service performed by process 1700, only certain users ofthe organization may be allowed to update policy for KeyIDs. Policyinformation may indicate which users are able to cause the cryptographyservice to update policy for the KeyID and/or even whether the policy isupdatable according to an existing policy. For example, a cryptographyservice may, in some embodiments, receive request to enforce a newpolicy. The cryptography service may check whether any existing policyallows the new policy to be put into place. If the cryptography servicedetermines that the existing policy does not allow enforcement of thenew policy, the request may be denied. Generally, the policy informationmay be any information usable for the enforcement of policy applicableto the requestor.

As illustrated in FIG. 17, the process 1700 includes using the accesspolicy information to determine 1704 whether policy allows the requestedupdate to be performed. If it is determined 1714 that the policy doesnot allow the requested update to be performed, the process 1700 mayinclude denying 1710 the request such as described above. If, however,it is determined 1714 the policy allows the requested update to beperformed, the process 1700 may include updating 1716 policy for theKeyID. Updating policy for the KeyID may include updating policyinformation and having the updated policy being stored in accordancewith or in association with the KeyID. The updated policy informationmay be stored, for example, by a policy enforcement module of thecryptography service such as described above, in connection with FIG.16.

Policy may also be enforced by other components of an electronicenvironment that operate in connection with a cryptography service. Forinstance, referring FIG. 2, discussed above, a cryptography service mayprovide an electronic representation of a policy to the data servicefrontend for the data service frontend to enforce. Such may be useful incircumstances where the data service is better suited to enforce thepolicy. For example, whether an action is allowed by policy may be basedat least in part on information accessible to the data service frontendand not to the cryptography service. As one example, a policy may dependon data stored by the data service backend storage system on behalf of acustomer associated with the policy.

As discussed above, a cryptography service may include various systemsthat allow for the enforcement of policy in accordance with policy onkeys having KeyIDs. FIG. 18, accordingly, shows an illustrated exampleof a process 1800 which may be used to enforce policy. The process 1800may be performed by any suitable system such as by a cryptographyservice system such as described above in connection with FIG. 16. In anembodiment, the process 1800 includes receiving 1802 a request toperform one or more cryptographic operations using a key having a KeyID.While FIG. 18 illustrates the process 1800 as being performed inconnection with a request to perform one or more cryptographicoperations, it should be noted that the process 1800 may be adapted foruse with any request to perform an operation which is not necessarilycryptographic. Example operations are described above.

A determination may be made 1804 whether the received request isauthentic. Determining whether the received request is authentic may beperformed in any suitable manner such as described above. For instance,determining 1804 whether the request is authentic may include submittingan authentication request and receiving an authentication response suchas described above. If it is determined 1804 that the request is notauthentic, the process 1800 may include denying 1806 the request.Denying 1806 the request may be performed in any suitable manner such asdescribed above. If, however, it is determined 1804 that the request isauthentic, the process 1800 may include accessing 1808 policyinformation for the KeyID and/or the requestor. Accessing policyinformation for the KeyID and/or request may be performed in anysuitable manner. For example, accessing policy information for the KeyIDand/or requestor may be performed by accessing the storage policyinformation from one or more storage systems that store such policyinformation. The access policy information may be used to determine 1810whether policy allows the one or more operations to be performed.

If it is determined 1810 that policy does not allow the one or moreoperations to be performed, the process 1800 may include denying 1806the request. If, however, it is determined that policy does allow theone or more operations to be performed, the process 1800 may includeperforming 1812 the requested one or more cryptographic operations. Oneor more results of performance of the one or more cryptographicoperations may be provided 1814 such as provided to the requestor thatsubmitted the received 1802 request to perform the one or morecryptographic operations. In some embodiments information derived atleast in part from allowed requests and or denied requests may beprovided through an audit subsystem.

As discussed, embodiments of the present disclosure allow for flexiblepolicy configuration and enforcement. In some embodiments, policies maystate which services can perform which operations in which contexts. Forexample, a policy on a key may allow a data storage service to cause thecryptography service to perform encryption operations but not decryptionoperations. A policy on a key may also include one or more conditions onthe ciphertext and/or decrypted plaintext. For example, a policy mayrequire that the ciphertext and/or plaintext produce a certain hashvalue (which may be a keyed hash value) before results of an operationbe provided in response to a request. Policies may specify one or morerestrictions and/or permissions that are based at least in part on time,Internet Protocol (IP) from which requests originate, types of contentto be encrypted/decrypted, AAD, and/or other information.

Numerous variations are considered as being within the scope of thepresent disclosure. For example, various embodiments discussed abovediscuss interaction with a separate authentication service. However,components of the environments discussed above may have their ownauthorization components and determining whether requests are authenticmay or may not involve communication with another entity. Further, eachof the environments discussed above are illustrated in connection withparticular operations and capabilities enabled by the environments. Thetechniques discussed above in connection with different environments maybe combined and, generally, environments in accordance with the presentdisclosure may allow for flexible use of the various techniques. As justone example, a cryptography service may be used to, upon request,encrypt both keys and other content, such as non-key data objects. Asanother example, a cryptography service may be configured to receive andrespond to requests from both users (e.g., customers of a computingresource provider) and other services (e.g., data storage services). Insome embodiments, a cryptography service and/or associatedauthentication service may be configured for use with a mobile device toperform encryption of stored data. In some embodiments at least oneunlock pin may be validated by a cryptography service. In still otherembodiments a cryptographic service, as part of an operation, mayreceive information generated by a hardware attestation. In someembodiments a cryptography service may be operable to provide digitalrights management services with respect to content.

As discussed above, various embodiments of the present disclosure allowfor rich policy enforcement and configurability. Many cryptosystemsprovide for authenticated encryption modes of operation wherecryptographic operations can be performed to simultaneously provideconfidentiality, integrity, and authenticity assurances on data.Confidentiality may be provided by encryption of plaintext data.Authenticity may be provided for both the plaintext and for associateddata which may remain unencrypted. With such systems, changes to eitherthe ciphertext or associated data may cause decryption of the ciphertextto fail.

In an embodiment, data associated with plaintext is used in theenforcement of policy. FIG. 19, accordingly, shows an illustrativeexample of a process 1900 for encrypting data in a manner that allowsfor policy enforcement using associated data in accordance with variousembodiments. The process 1900 may be performed by any suitable system,such as a cryptography service and/or a security module. As illustrated,the process 1900 includes obtaining 1902 plaintext. The plaintext may beobtained in any suitable manner. For example, in a service providerenvironment such as described above, a user (e.g., customer) may providedata to be encrypted. As another example, obtaining 1902 may includegenerating a key (to be encrypted) and/or obtaining a key to beencrypted. The key may be used, such as described above.

As shown, the process 1900 includes obtaining associated data. Theassociated data may be any data that is associated with or is to beassociated with the plaintext. The associated data may be any data onwhich one or more policies are, at least in part, based. Examples appearbelow. Further, the associated data may be encoded in any suitablemanner, such as in eXtensible Markup Language (XML), JavaScript ObjectNotation (JSON), Abstract Syntax Notation One (ASN1), YAML Ain't MarkupLanguage (also referred to as Yet Another Markup Language) (YAML) oranother structured extensible data format. In an embodiment, the process1900 includes generating 1906, based at least in part on the plaintextand the associated data, a message authentication code (MAC) andciphertext. The combination of a MAC and ciphertext, such as the outputof the AES-GCM cipher, may be referred to as authenticated ciphertext.Generating the MAC and ciphertext may be performed in any suitablemanner and generation of the MAC and ciphertext may depend on whichcryptosystem(s) is/are used. For example, in an embodiment, the advancedencryption standard (AES) supports associated authenticated data (AAD)when operated in either CCM mode or GCM mode, where CCM representsCounter with CBC-MAC, GCM represents Galois/Counter Mode, and CBCrepresents a cipher block chaining. Using AES in either CCM or GCM mode,the plaintext and associated data may be provided as inputs to obtainoutput of the concatenated pair of the ciphertext and a MAC of both theplaintext and associated data. It should be noted that while AES-CCM andAES-GCM are provided for the purpose of illustration, otherauthenticated encryption schemes may be used and the techniquesdescribed explicitly herein can be modified accordingly. For example,techniques of the present disclosure are applicable, in general, tosymmetric block ciphers supporting authenticated encryption modes. Inaddition, other encryption schemes are combinable with MAC functions inaccordance with various embodiments of the present disclosure. Suitableencryption scheme and MAC function combinations include, but are notlimited to, those where the encryption scheme is semantically secureunder a chosen plaintext attack and the MAC function is not forgeableunder chosen message attack. Further, while various embodiments of thepresent disclosure utilize ciphers that result in a single output thatencodes both the ciphertext and the MAC, the MAC and ciphertext may begenerated using different ciphers. Further, while MACs are used asillustrative examples, other values not generally referred to as MACsmay also be used, such as general hashes, checksums, signatures, and/orother values that can be used in place of MACs. Accordingly, cipherswith automated encryption modes that support associated data includeciphers that use other cryptographic primitives in addition to or as analternative to MACs.

Further, generating the MAC and ciphertext may be performed in variousways in accordance with various embodiments. For example, in anembodiment, the plaintext is provided to a security module, such asdescribed above. The security module may be configured to generate theMAC. In other embodiments, a component of an electronic environmentother than a security module generates the MAC and ciphertext. In suchembodiments, a security module may be used to decrypt a key that, whenin plaintext form, is used to generate the MAC and ciphertext. Oncegenerated, the MAC and ciphertext (i.e., authenticated ciphertext) maybe provided 1908. In some embodiments, the associated data is alsoprovided. The MAC and ciphertext may be provided in various ways invarious implementations making use of the process 1900 and variationsthereof. For example, in some embodiments, the MAC and ciphertext areprovided to a user, such as described above, or provided to a dataservice, such as described above, for processing by the data service.Further, as noted, while the associated data may be provided, in variousembodiments, the associated data is not provided and/or it is generallypersisted in plaintext form. As an example, the associated data may notbe provided if it is independently obtainable. As an illustrativeexample, if the associated data is a persistent identifier of a device(e.g., an identifier of a storage device), the associated data may beobtained at a later time when needed for policy enforcement and/or forother purposes.

As discussed above, various embodiments of the present disclosureutilize security modules to provide enhanced data security. FIG. 20provides an illustrative example of a process 2000 that may be used toencrypt data in a manner allowing for novel and rich policy enforcement,in accordance with various embodiments. The process 2000 may beperformed by any suitable system, such as a cryptography service and/ora security module. As illustrated in FIG. 20, the process 2000 includesobtaining plaintext and associated data. As above, the plaintext andassociated data may be received in a single communication, in separatecommunications and/or from separate entities. Once obtained, theplaintext, associated data, and a KeyID are provided 2004 to a securitymodule. The security module may be such as described above. Further, thesecurity module may be selected from multiple security modulesparticipating in an electronic environment, such as an environmentsupporting a cryptography service, such as described above. The KeyIDmay be as described above and may be specified in a request to encryptthe plaintext submitted to a cryptography service or may otherwise bespecified. Further, in alternate embodiments of the process 2000, aKeyID may not be specified. For instance, in some embodiments, asecurity module may select a KeyID and/or may generate a key that islater assigned a KeyID. In such embodiments, the process 2000 may bemodified to provide the KeyID from the security module.

Returning to the illustrated embodiment, the process 2000 may includereceiving 2006 from the security module ciphertext and a MAC. Theciphertext may be encrypted under the key identified by the KeyID. TheMAC may be a MAC over a combination of both the plaintext and associateddata such that a change to the ciphertext or associated data will causea check on the MAC to fail. As above, it should be noted that variationsinclude those where the MAC is generated based at least in part on theassociated data but independent of the plaintext. Further, as discussedabove, the ciphertext and MAC may be provided together (such as fromoutput of use of an AES-CCM or AES-GCM cipher) or may be providedseparately. Once received from the security module, the MAC andciphertext are provided 2008 to an appropriate entity, such as a user ofa cryptography service or a data service that operates in connectionwith a cryptography service, such as described above.

As discussed above, a security module may be used in various ways toenhance the protection of data. As discussed above, in some embodiments,security modules are used to encrypt keys that are used (in theirplaintext form) to encrypt other data. FIG. 21 accordingly shows anillustrative example of a process 2100 that can be used in suchcircumstances. The process 2100 may be performed by any suitable system,such as a cryptography service and/or a security module. The process2100, in an embodiment, includes obtaining 2102 plaintext and associateddata, such as described above. As illustrated, the process 2100 includesproviding 2104, to a security module, an encrypted key, associated data,and KeyID identifying a key usable by the security module to decrypt theencrypted key. Accordingly, the process 2100 includes obtaining adecrypted key from the security module that used the key identified bythe KeyID to decrypt the encrypted key. Once obtained, the key can beused to encrypt the plaintext, thereby calculating 2108 ciphertext and aMAC. The ciphertext may be an encryption of the plaintext and the MACmay be over (i.e., based at least in part on) the associated data orboth the associated data and plaintext, such as described above. Onceencrypted, the process 2100 may include providing 2110 the MAC andciphertext such as described above. Further, the process may alsoinclude losing 2112 access to the decrypted key, which may be performedin any suitable manner, such as by a SecureErase operation, overwritingmemory storing the decrypted key, removing power to volatile memorystoring the key and/or in any other way in which a system performs theprocess 2100 (e.g., a cryptography system absent its security modules).While illustrated in parallel, providing the associated data, MAC,and/or ciphertext and losing access to the key may be performed insequence, the order of which may vary among the various embodiments.

FIG. 22 shows an illustrative example of a process 2200 that may be usedto enforce policy using associated data, in accordance with variousembodiments. The process 2200 may be performed by any suitable system,such as a cryptography service and/or a security module. In anembodiment, the process 2200 includes receiving 2202 a request toperform an operation. The request may be any request submitted to aservice that processes requests. In an embodiment, the request is arequest to perform a cryptographic operation submitted to a cryptographyservice. In response to receiving 2202 the request, the process 2200 mayinclude obtaining 2204 ciphertext, a MAC, and expected associated data.Obtaining 2204 the ciphertext, MAC, and expected associated data may beperformed in any suitable manner. For example, in some embodiments oneor more of the ciphertext, MAC, and expected associated data arereceived in the request. Two or more of the ciphertext, MAC and expectedassociated data may be received in separate requests or othercommunications and/or accessed from a data store, such as a local datastore. For example, in an embodiment, the ciphertext and MAC arereceived as a concatenated pair (possibly generated from output of anAES-GCM or AES-CCM cipher) as part of the request. The expectedassociated data may also be part of the request or may be identified inother ways. For example, an identity of the requestor may be used,directly or indirectly, to determine the associated data. As a specificexample, if the request is to perform an operation in connection withdata stored in a storage device, obtaining 2204 the associated data mayinclude obtaining an identifier of the data storage device. Theidentifier may be identified explicitly (e.g., as part of the request)or implicitly (e.g., because other information is available to determinethat the data is stored in the data storage device). The associated datamay be or may otherwise be based at least in part on the identifier ofthe data storage device. As discussed above, the associated data mayvary greatly among the various embodiments.

In an embodiment, the process 2200 includes generating 2206 a referenceMAC usable to determine the authenticity of the expected associateddata. For example, the ciphertext, associated data, and an appropriatekey (which may be identified in the request or may be otherwisedetermined) are used to generate 2206 a reference MAC. Generating theMAC may be performed in any suitable manner, such as by using the samecipher that was used to obtain the ciphertext. A determination may bemade 2208 whether the reference MAC and the obtained MAC match. Forexample, in many cryptosystems, MACs match when they are equal, althoughit is contemplated that other types of matching may be used in variousembodiments. If it is determined 2208 that the reference MAC andobtained MAC match, in an embodiment, the process 2200 includesaccessing 2210 policy information based at least in part on theassociated data. Accessing 2210 the policy information may includeaccessing one or more policies (i.e., electronic representations of theone or more policies) from a remote or local data store based at leastin part on the one or more policies associated with a KeyID used togenerate the reference MAC and/or perform another cryptographicoperation.

A determination may then be made 2212, based at least in part on theaccessed policy information, whether policy allows the requestedoperation to be performed (e.g., whether policy allows the request to befulfilled). Determining whether the policy allows the requestedoperation to be performed may include determining whether the ciphertextis tagged with associated data specified by the accessed policyinformation. Further, while not illustrated, policy information that isnot based at least in part on associated data (e.g., policies based oninformation other than associated data) may also be used to determinewhether policy allows the operation to be performed. If determined 2212that policy allows the operation, the process 2200 may includeperforming 2214 the operation. If, however, it is determined 2212 thatpolicy does not allow the operation, and/or if determined 2208 that thereference MAC and obtained MAC do not match, the process 2200 mayinclude denying 2216 the request, such as described above.

Various policies are enforceable using the techniques described above.For example, as noted, policies may be associated with keys such that,when enforced, the policies determine what can and/or cannot be donewith the keys. As one example, a policy may state that a data servicecan use a key only for certain types of operations specified by thepolicy (or, alternatively, that certain operations are prohibited to thedata service). A policy may also specify conditions on use, time of use,IP address, what may be encrypted, what may be decrypted, and the like.As one illustrative example, one policy may specify that providing adecrypted result is allowed only if a hash of the decryption matches aspecified value. Thus, a cryptography or other service enforcing thepolicy would not provide plaintext if a hash of the plaintext was not inaccordance with the policy. As another example, a policy may specifythat decryption of ciphertexts is allowed only if the ciphertexts aretagged with associated data equal to or beginning with a specifiedvalue. As yet another example, a policy may specify that decryption ofciphertexts is allowed only if the ciphertexts are tagged with anidentifier of a storage device encoded in associated data.

Generally, policies may specify restrictions and/privileges that arebased at least in part on the value of data associated with a ciphertext(i.e., authenticated associated data). Some additional policies includepolicies that specify decryption is only allowed on ciphertext taggedwith an identifier of a computer requesting decryption, ciphertexttagged with an identifier of a storage volume mounted (operationallyconnected) to a computer requesting decryption, and/or ciphertext taggedwith identifiers of other computing resources. The computing resourcesmay also be computing resources hosted by a computing resource providerthat enforces the policies. Other policies are considered as beingwithin the scope of the present disclosure, such as policies that arebased at least in part on the input and/or output of a cryptographicalgorithm before the output of the cryptographic algorithm is revealedto an entity outside of the entity performing the cryptograph algorithm(e.g., revealed to a user and/or other data service outside of acryptography service enforcing the policies). As noted above, policiesmay also specify conditions, which may be based at least in part onassociated data, for when policies may be modified.

FIG. 23 shows an illustrative example of a process 2300 which is avariation of the process 2200 discussed above in connection with FIG.22, where the variation illustrates the use of a security module inenforcing policy, in accordance with various embodiments. In anembodiment, the process 2300 includes receiving 2302 a request todecrypt ciphertext, which may be an encrypted key or other encrypteddata. The process 2300 also includes obtaining 2304 the ciphertext, MAC,and expected associated data, such as described above in connection withFIG. 22. As illustrated in FIG. 23, in an embodiment, the process 2300includes using 2306 a security module to decrypt the ciphertext. Using2306 a security module may also include selecting a security module froma plurality of security modules operable to decrypt the ciphertext,thereby producing plaintext. The security module may also be used 2308to generate a reference MAC based at least in part on the plaintext andthe expected associated data. It should be noted that, while shown astwo separate steps in FIG. 23, using the security module to decrypt theciphertext and generate the reference MAC may be performed in a singleoperation (e.g., a single request to the security module). Once obtainedfrom the security module, the process 2300 includes determining 2310whether the reference MAC and the obtained MAC match, such as describedabove in connection with FIG. 22. It should be noted, however, that insome embodiments, the process 2300 may be modified so that the securitymodule is provided the reference MAC and determines whether thereference MAC and the obtained MAC match. In this variation, thesecurity module may provide a response indicating whether there is amatch.

Returning to the embodiment illustrated in FIG. 23, if it is determined2310 that the reference MAC and obtained MAC match, the process 2300includes accessing 2312 policy information based at least in part on theassociated data, such as described above in connection with FIG. 22.Also, as above, while not illustrated as such, additional policyinformation regarding policies not based at least in part on associateddata may also be accessed. A determination may be made 2314 whetherpolicy allows the operation. If determined 2314 that policy does allowthe operation, the plaintext may be provided 2316. As above inconnection with FIG. 22, if determined 2314 that policy does not allowthe operation and/or if determined that the reference MAC does not matchthe obtained MAC, the process may include denying 2318 the request, suchas described above.

While various embodiments of the present disclosure are illustratedusing associated data of an authentication mode of a cipher, otherembodiments are also considered as being within the scope of the presentdisclosure. For example, embodiments of the present disclosure generallyapply to the use of data that is verifiable with ciphertext to enforcepolicy. As an illustrative example, a representation of a policy can becombined with a first plaintext to generate a new plaintext (e.g., a newplaintext comprising the plaintext and the policy). The new plaintextcan be encrypted using a suitable cipher, such as AES, to produce aciphertext. When a request to decrypt the ciphertext is received, asystem receiving the request may decrypt the ciphertext, extract thepolicy from the new plaintext, and check whether the policy allows thefirst plaintext to be provided. If policy does not allow for the firstplaintext to be provided, the request may be denied. Such embodimentsmay be used instead of or in addition to the embodiments discussed abovein connection with associated data of an authentication mode of acipher.

Various embodiments of the present disclosure also allow for policies onkeys that specify conditions for how auditing takes place. For example,a policy on a key may specify an audit level for a key, where the auditlevel is a parameter for a cryptography service that is determinative ofhow the cryptography service audits key use. Auditing may be performedby any suitable system. For example, referring to FIG. 16, the requestprocessing unit may communicate with an auditing system (not shown) thatmay be part of or separate from the cryptography service. When eventsoccur in connection with the performance of cryptographic operations,relevant information may be provided to the auditing system that logsthe information. Events may be requests to perform cryptographicoperations and/or information indicating whether the requestedoperations were performed. For example, if a user successfully requeststhe cryptography service to perform a decryption operation, thecryptography service may provide the auditing system information toenable the request and that the operation was performed. Administrativeaccess events and, generally, any interaction or operation of thecryptography service may be logged with relevant information which mayidentify entities involved in the events, information describing theevents, a timestamp of the events, and/or other information.

In an embodiment, audit levels include a high-durability level and alow-durability level. For a low-durability level, audit operations for akey may be performed by a cryptography service on a best-effort basis.With auditing according to a low-durability level, during normaloperation, all operations are audited but, in the event of a failure ofa component of the cryptography service, some audit data may be lost.With auditing according to a high-durability level, before revealing theresult of a cryptographic operation, an assurance, that an audit recordthat the operation has occurred has been durably committed to memory, isobtained. Because of the acknowledgment needed, operations in highdurability audit mode are slower than operations in low durability auditmode. The assurance that the audit record has been durably committed tomemory may include an acknowledgment from one or more other systems usedto store audit records. Thus, referring to the previous paragraph, acryptography service may delay providing plaintext to a user until anacknowledgement from the auditing system that a record of the decryptionresulting in the plaintext has been durably committed to memory. Durablycommitted to memory may mean that the data has been stored in accordancewith one or more conditions for durability. For example, the data may bedurably committed to memory when the data is written to non-volatilememory and/or the data has been redundantly stored among a plurality ofdata storage devices (e.g., using an erasure coding or other redundancyencoding scheme).

In an embodiment, a cryptography service uses sub-levels for thelow-durability and high-durability audit levels. For example, in anembodiment, each level corresponds to two separate states, an immutablestate and a mutable state. Whether the state is immutable or immutablemay determine how and whether transitions between states are to occur.For example, using the illustrative example of audit durability, policyon a key may be able to change between low-durability mutable andhigh-durability mutable, from low-durability mutable to low-durabilityimmutable, and from high-durability mutable to high-durabilityimmutable. However, a cryptography service may be configured such that,once the policy for the key is in either low-durability immutable orhigh-durability immutable, transition is prohibited. Thus, once thepolicy for a key is in an immutable state, the policy cannot be changed.

In addition, various embodiments of the present disclosure allow forpolicy changes to become effective without having to wait for the policychanges to propagate throughout a distributed system. In someembodiments, a policy change is provided to the distributed system by anentity (e.g., system administrator or management system) authorized tomake the change. The distributed system may propagate the policy changeto devices affected by the policy change, such as a fleet of devicesinvolved in access control in connection with various computingresources. Propagation of the policy change may occupy an amount of timebefore all affected devices have received the change.

To enable the distributed system to operate in accordance with thepolicy before the policy change has finished propagation, in variousembodiments, a token is generated and provided to entities (e.g., userdevices and/or components of the distributed system) that access theresource(s) to which the policy applies. For example, the token may beprovided to principals to which the policy applies. The token maycomprise or otherwise be associated with information that enables anaccess control system to evaluate whether policy allows fulfillment ofthe request before the policy change has been propagated to the accesscontrol system. For example, in some embodiments, the token comprises arepresentation of the policy change, one or more identifiers of one ormore principals affected by the policy, information from which validityof the token can be verified, and/or information from which authenticityof the token can be verified.

The information from which validity of the token can be verified mayinclude a timestamp and/or a sequence number that can be checked todetermine whether the policy represented in the token has been revokedor otherwise superseded by another policy change that has beenpropagated. Generally, the information from which the validity of thetoken can be verified may be any information that serves to provide alimit on the lifetime of the token's validity. The information fromwhich the authenticity of the token can be verified may be, for example,an electronic signature of the token that is signed using an appropriatekey, such as a key shared by the device generating the token and one ormore devices that are operable to verify the authenticity of the token,or a public key from a public-key signature scheme. Generally, theinformation from which the authenticity of the token can be verified maybe any information that allows an accurate determination whether thecontents of the token have been modified since its verification and/orinformation that allows a bearer of the token to prove access to secretinformation (e.g., a cryptographic key).

As noted, a token generated in accordance with various embodimentsdescribed herein may be used to access a computing resource before adevice controlling access to the resource has been notified of a policychange allowing such access. A principal of the changed policy may, forexample, provide the token with a request to access the resource. Adevice receiving or otherwise involved in processing the request, thathas not otherwise received a policy change encoded by the token, mayanalyze the token to determine whether the token is sufficient forallowing the request to be fulfilled. This determination may include anumber of other determinations, such as whether the token is valid,whether the token is authentic, and/or whether, even if the token isvalid and authentic, the policy allows fulfillment of the request.

In various embodiments, tokens have finite lifetimes. The length of atoken's validity may be predetermined (e.g., by a timestamp encoded inthe token) or may be otherwise limited by the occurrence of one or moreevents. For instance, a token may include information (e.g., a sequencenumber) that can be analyzed to determine whether the token is stale dueto the corresponding policy change already having been received throughpropagation. For example, the information may be a global policysequence number utilized by a central policy management system. Uponreceipt of a token by a device involved in access control, the sequencenumber in the token can be compared with a latest received policy updatesequence number. If the sequence number in the token is greater than thelast received policy update sequence number, the policy change encodedin the token may be honored (assuming any other requirements are alsomet). If the sequence number in the token is less than or equal to thelast received policy update sequence number, the policy change encodedin the token may be ignored. In this manner, if a subsequent policychange revokes or otherwise contradicts the policy change encoded in thetoken, the receipt of the propagated subsequent policy change serves toinvalidate the token from the perspective of the system that receivedthe propagated subsequent policy change. In this manner, the token isusable for access for a limited amount of time.

Various embodiments of the present disclosure may also allow forexpedited policy enforcement. For example, in some embodiments, systemsinvolved in access control maintain a cache of policies. The cache maybe utilized to reduce the need to communicate with another authorizationsystem or other policy authority. In various embodiments, when a systeminvolved in access control receives a token, policy encoded in the tokenmay be used to update a policy cache. The policy updated in the cachemay include an expiration time enforced by the cache so that, even ifthe policy change never gets propagated to the system, the token'seffect on policy has a limited time span. However, under normalcircumstances, the update of the cache to reflect the policy encoded inthe token allows for the cache to be utilized to more quickly evaluatepolicy at least for a period of time until the policy is propagated froman authoritative source.

FIG. 24 shows an illustrative example of an environment 2400 which maybe used to implement various embodiments of the present disclosure. Asdiscussed above, various embodiments of the present disclosure relate topolicy changes in the distributed system such that the policy changescan be treated as effective immediately, while the distributed systemreconfigures itself (e.g., by updating access control devices) tooperate in accordance with the policy. As illustrated in FIG. 24, apolicy updater receives a policy update from a user. A policy updatermay be a computer system operable to update policies in the distributedsystem. The policy updater may be, for example, a subsystem of a centralpolicy management system of the distributed system. While illustrated asflowing from the user to the policy updater, the policy update may beprovided to the policy updater in various ways. In some embodiments, theuser provides the policy update directly to the policy updater and, inother embodiments, the policy update is provided to the policy updaterindirectly. For example, the policy update may be provided to the policyupdater by another system as a result of the user interacting with theother system. While illustrated as a human figure in the figures, itshould be noted that, as in other portions of the present disclosure,users herein are used to denote any entity that may interact withanother computer system. For example, a user may be a human operatorproviding input through a user device. A user may also be any computingdevice operable to communicate with another communicating device. Humaninteraction with the computing device is not necessarily required. Forexample, the user may be an automated system that communicates withother systems according to its programming logic.

As illustrated in FIG. 24, upon receipt of a policy update, the policyupdater performs at least two actions. As illustrated, the policyupdater causes the policy update to be propagated to other components ofthe distributed system. The policy updater may, for example, write to adatabase of policy updates that is utilized by a policy propagationsystem to manage and update policies throughout the distributed system.As another example, the policy updater may transmit the policy update toapplicable components of the distributed system over a network itself.Also as illustrated, the policy updater provides a token to the user. Inan embodiment, the token is usable to cause the distributed system tooperate in accordance with the policy without the policy having beencompletely propagated. For example, in an embodiment, the token containsinformation that, as described in more detail below, causes a componentof the distributed system to operate in accordance with the policyupdate despite not having received the policy update through propagationby the policy updater. For instance, in an embodiment, the tokenincludes information representing one or more principals affected by thepolicy update, a representation of the policy update information fromwhich a determination of the token's validity can be determined and/orinformation from which the authenticity of the token may be determined.The representation of the one or more principals affected by the policymay be, for example, identifiers of entities (e.g., users, devices,subsystems, etc.) to which access is granted by the policy where theidentifiers are utilized by the distributed system to identify theentities. The policy update encoded by the token may be encoded in anysuitable manner, such as using a suitable policy language to encode thepolicy or the information representing changes to an existing policy.For example, the policy may be encoded in eXtensible Markup Language(XML), JavaScript Object Notation (JSON), Abstract Syntax Notation One(ASN1), YAML is Not a Markup Language (YAML, also referred to as YetAnother Markup Language), or another extensible structured data format.The information from which the validity of the token may be determinedmay include information from which a determination may be made whetherthe token is stale, that is, whether the token has become invalid.

In various embodiments, tokens may become invalid for various reasons.For example, in some embodiments, tokens are valid for a predeterminedamount of time. The information from which the token's validity may bedetermined may, therefore, include a timestamp, which may encode a timeat which the token was generated (for use as a basis for enforcing atoken lifetime limit programmed into a system) and/or a time in whichthe token is to expire. Other information may be used instead of, or inaddition to, a timestamp. For example, in an embodiment, a distributedsystem utilizes global sequence numbers for policy updates. Thus, eachpolicy update that is made in the system may, for instance, include anupdated sequence number. The sequence number may be encoded in the tokento enable a distributed system to determine whether a subsequent policyhas been propagated. For example, a component of the distributed systeminvolved in access control that receives a token may look at a sequencenumber in the token and compare that sequence number to a sequencenumber of a policy update received through propagation. If the latestpolicy received through propagation is greater than the sequence numberof the token, the component may therefore determine that any policyencoded in the token would have been reflected in policy changesreceived through propagation. In this manner, the policy updater of thetoken may be ignored and the policy may be enforced regardless of anyinformation in the token.

As illustrated in FIG. 24, a user may utilize the token for access to acomputing resource. It should be noted that while FIG. 24 shows twousers, the two users may be the same user or different users. Forexample, in some embodiments, the user represented in the upper portionof FIG. 24 may be a user with authority to provide access to otherusers, one of which is represented by the user in the lower portion ofthe FIG. 24. (As noted above, users are not necessarily humanoperators.) To use a token for access, the user may provide the token toa node of a service implemented by the distributed system, such as ahost configured to receive requests to the service. The user, forexample, may submit a request to a service node that has yet to receivea policy update through propagation. The token may be provided with therequest or otherwise in connection with the request. The service nodemay analyze or cause to be analyzed information in the token not todetermine whether the policy allows the request to be fulfilled, but todetermine whether to ignore the token and/or determine whether thepolicy allows the request to be fulfilled. If the service nodedetermines that the policy allows the request to be fulfilled, eitherthrough analysis of the token or through evaluation of policy, theservice node may provide to the user access to the service. The servicemay be any service implemented by a distributed system for which accesscontrol is applicable. Examples appear above and below.

FIG. 25, accordingly, shows an illustrative example of an environment2500 illustrating various aspects of the present disclosure. Theenvironment 2400 illustrated above in connection with FIG. 24 may beused. As illustrated in FIG. 25, a computing resource service includes aresource management system and a plurality of computing resources. In anembodiment, the computing resources are virtual computer systems and theresource management system is a system configured to provision, monitor,deprovision, and otherwise manage the computing resources. It should benoted that, while virtual computer systems are used throughout for thepurpose of illustration, the computing resources are generally resourcesto which access control applies and not necessarily virtual computersystems. In an embodiment, the resource management system of thecomputing resource service receives a computing resource request from auser. The user may be a user such as described above, which is notnecessarily a human user, but more generally a caller to the computingresource service.

Continuing the example of virtual computer systems as computingresources, the computing resource request may be a request made inconnection with a particular virtual computer system instance. Forexample, for the purpose of illustration, in an embodiment, thecomputing resource request may be a request to attach a volume to aparticular computer system instance. The request may be, for example, arequest to logically attach a virtual volume to a virtual computingsystem instance. The virtual volume may be, for example, a virtual blockdata storage device. It should be noted that virtualization is used forthe purpose of illustration and that various aspects of the presentdisclosure do not necessarily utilize virtualization. For example, therequest may be a request to attach a data storage device to a computersystem where zero, one or both of the data storage device and computersystems are virtual. Attachments may refer to logical attachment andlogical attachment does not necessarily include physical attachment. Forexample, in an embodiment, the computer system instance and the datastorage device are separated by a network. The computer system instancemay, however, include an application that enables an operating system ofthe computer system instance to interact with the data storage device asif the data storage device was physically attached to the computersystem instance. The application may, for example, translate requests tothe data storage device from the operating system into network requeststhat are transmitted to the data storage device. The response maylikewise be transformed from network responses to a format appropriatefor use by the operating system.

Returning to the flow illustrated in FIG. 25, the computing resourcerequest received by the resource management system triggers a policychange. The resource management system may be a system, for example,that is authorized to make such policy changes. Continuing the exampleof a computer system instance and a data storage device, the policychange triggered by the computing resource request may be a change thatallows a particular computing resource to access a particular key neededto decrypt information stored by the data storage device. The key may bemanaged by a cryptography service, such as described above. Accordingly,in an embodiment, the resource management system transmits the policy tothe cryptography service that manages the key and any policiesassociated with the key. The cryptography service may generate or havegenerated a token that the cryptography service provides to the resourcemanagement system. The resource management system may then provide thetoken to the computing resource to which the computing resource requestapplied. The computing resource that receives the token from theresource management system may then provide the token and ciphertext tothe cryptography service. Providing the token and ciphertext to thecryptography service may include communication with a host of thecryptography service that has yet to receive the policy throughpropagation. The host may then evaluate the token and determine whetherto provide plaintext to the computing resource. If the host determinesthat the token and policy included therein allow plaintext to beprovided, the host may cause the cryptography service to decrypt theciphertext text and the host may then provide the plaintext in return.The ciphertext may be an encrypted key that when decrypted is usable todecrypt data on a data storage device. The plaintext may then be thedecrypted version of the key. The computing resource may then utilizethe decrypted version of the key to decrypt the contents of the datastorage device and otherwise operate with that data.

FIG. 26 shows an illustrative example of a process 2600 for enablingcomputing resource access. The process 2600 may, for example, be used bya resource management system described above in connection with FIG. 25or generally any suitable system involved in requests made in connectionwith computing resources. In an embodiment, the process 2600 includesreceiving 2602 a request to allow a first computing resource to access asecond computing resource. Using the example of FIG. 25, the firstcomputing resource may be a computer system instance and a secondcomputing resource may be a key managed by a cryptography service.Accessing the second computing resource may in some embodiments notinclude actually obtaining the second computing resource, but continuingthis example, may include[??] causing the cryptography service toutilize the second computing resource to perform one or morecryptographic operations and receiving results of the performed one ormore cryptographic operations. In other words, accessing a resource may,in some embodiments, not include obtaining the resource, but may includecausing a computer system to perform one or more operations inconnection with the resource. Generally, however, the first computingresource and second computing resource can be any resources in variousembodiments.

As a result of having received 2602 the request to allow the firstcomputing resource to access the second computing resource in anembodiment, the process 2600 includes sending 2604 a policy update tothe cryptography service. While not illustrated as such, thecryptography service may cause propagation of the policy update asappropriate. A component of the cryptography service that received thepolicy update may, for example, cause a propagation system of thecryptography service to receive the policy update to enable thepropagation system to provide the policy updates to applicable hosts ofthe cryptography service. In addition, or as an alternative, ifapplicable, the cryptography service or entity that received the requestto allow the first computing resource to access the second computingresource may cause a global policy management system of a computingresource provider that implements the cryptography service to propagatethe updated policy for the cryptography service and for one or moreother services implemented by the computing resource provider.

Upon having sent 2604 the policy update to the cryptography service, theprocess 2600 may include receiving 2606 a token from the cryptographyservice where the token may be a token such as described above. Thetoken may then be provided 2608 to the first computing resource (or to asystem having access to the first computing resource, if applicable,such as when the resource is not operable to utilize the token itself).For example, continuing the example above, if the first computingresource is a computer system instance providing the token may includeproviding the token to the computer system instance over a network. Asnoted, while FIG. 26 shows providing 2608 the token to the firstcomputing resource, variations may include providing the token to acomputer system that manages the first computing resource and notnecessarily to the resource itself.

FIG. 27 shows an illustrative example of a process 2700 for utilizing atoken in accordance with various embodiments. The process 2700 may beperformed by any bearer of a token, such as a computing resource, suchas described above, in connection with FIG. 25 or any user using a tokenfor access to a resource. In an embodiment, the process 2700 includesreceiving 2702 a token. Receiving 2702 the token may be performed in anysuitable manner. For example, referring to the example of FIG. 25, thecomputing resource may receive the token from a computing resourcemanagement system. Having received or otherwise obtained the token, inan embodiment, the process 2700 includes submitting 2704 the token to acryptography service in connection with a request to decrypt the cyphertext. The token may be provided with the request (e.g., as part of therequest) or separately from the request but otherwise in connection withthe request. Assuming the token is acceptable to the cryptographyservice, the process 2700 includes receiving 2706 plaintext from thecryptography service. The cryptography service may, for example,determine whether policy allows the request to decrypt the ciphertext tobe fulfilled, such as described above. The policy may be obtained from apolicy store or from the token as applicable. The plaintext may then beused 2708 to access the second computing resource as illustrated in FIG.27. In the context of FIG. 27, the second computing resource may be, forexample, a data storage volume hosted by a computing resource provider.Generally, the second computing resource may be any resource for whichthe plaintext may be used to access. To avoid confusion, it should benoted that the second computing resource is not necessarily the samesecond computing resource such as described above in connection withFIG. 26.

FIG. 28 shows an illustrative example of a process 2800 for processingrequests in accordance with various embodiments. Operations of theprocess 2800 may be performed by appropriate components of a distributedsystem, such as described above. It should be noted that, as with allprocesses described herein, operations illustrated and/or otherwisedescribed in connection with FIG. 28 do not necessarily need to beperformed by the same computing device. For example, in a distributedsystem, different computing devices may perform different operations ofa process. In an embodiment, the process 2800 includes receiving 2802 apolicy update from a caller. The caller may be a user such as describedabove and generally a computing device operable to call a systemperforming the process 2800. As an example, referring to FIG. 25, apolicy may be received from a resource management system to acryptography service, although other environments (callers andreceivers) are considered as being within the scope of the presentdisclosure.

As a result of having received 2802 the policy update from the caller, apolicy update may be enqueued 2804 in a propagation stream of a systemperformed in the process 2800. The propagation stream may be a set ofpolicy updates organized into a data structure (e.g. afirst-in/first-out data structure) suitable for enabling propagation ofpolicy updates. Accordingly, enqueuing the policy update in thepropagation stream may be performed in any suitable manner, such as byadding the policy updates to a queue of policy updates that areprocessed by a propagation subsystem to propagate the policy updates tovarious components of a distributed system. A token corresponding to thepolicy update may also be provided 2806 to the caller. It should benoted that while illustrated in a particular order as with all processesdescribed herein, various operations do not necessarily have to beperformed in the operation they are illustrated. For example, enqueuingthe policy update and providing the token to the caller may be performedin a different order than illustrated or may be performed in parallel.In an embodiment, the process 2800 includes receiving 2808 a request andthe token from another caller. The other caller may, for example, havereceived the token from the caller to which the token was provided. Asnoted above, numerous individual computing devices may be involved inperformance of the process 2800. For example, a device that receives2808 the request and token from the other caller may be the same deviceor a different device than the device that receives 2802 the policyupdate from the caller.

In an embodiment, the process 2800 includes determining 2810 whether thetoken is valid. Determining 2810 whether the token is valid may beperformed in any suitable manner. For example, as noted above, a tokenmay include information from which the validity of the token may bedetermined. The information may include, for example, a timestamp,policy sequence number, and/or other information from which a processorof the token can determine whether the token and/or the manner by whichthe token is provided satisfies one or more conditions for validity.Accordingly, determining 2810 whether the token is valid may beperformed such as described above. If it is determined 2810 that thetoken is valid, the process 2800 may include determining 2812 whetherthe token is authentic. For example, in an embodiment, the tokenincludes an electronic signature and determining 2812 whether the tokenis authentic may include generating a reference signature anddetermining whether the reference signature matches the token'selectronic signature. It should be noted that for the sake of clarity,when a token is said to include an electronic signature, the signaturemay be generated based at least in part on a portion of the token otherthan the electronic signature. In other words, while various embodimentsdescribe the token as including the electronic signature, it should benoted that the electronic signature may be thought of as separate fromthe token where the token is the information from which the electronicsignature is generated. Further, while the process 2800 shows variousdeterminations being performed in a particular order, as with allprocesses described herein, variations of the order illustrated areconsidered as being within the scope of the present disclosure. Forexample, in some embodiments, determining whether the token is valid maybe performed only after determining that the token is authentic.

If it is determined 2810 that the token is invalid and/or it isdetermined 2812 that the token is authentic, the process 2800 mayinclude determining 2814 whether policy, as encoded by the token, allowsfulfillment of the request. It should be noted that, while notillustrated as such, additional policy checks may be performed even whenthe policy encoded by the token allows fulfillment of the request. Forinstance, even if the policy encoded by the token allows fulfillment ofthe request, a separate policy independent of the token may be checkedto determine whether the policy encoded by the token should be honored.As an illustrative example, if the policy encoded by the token wouldchange an existing policy that is immutable (e.g., unable to beadministratively changed), the request may be denied regardless ofwhether the policy encoded by the token would allow the request to befulfilled because existing policy would not allow the change in policyencoded by the token. If determined 2814 that the policy in the tokendoes not allow fulfillment of the request, the request may be denied2816, such as described above. Similarly, if determined 2814 that thepolicy in the token allows fulfillment of the request (and, ifapplicable, if the request is otherwise fulfillable), the request may befulfilled 2818.

If it is determined 2810 that the token is invalid or if it isdetermined 2812 that the token is not authentic, the process 2800 maynevertheless provide the opportunity for the request to be fulfilled,such as when existing policy would allow the request to be fulfilled.Accordingly, in an embodiment, if it is determined 2810 that the tokenis invalid or if it is determined 2812 that the token is not authentic,the process 2800 may nevertheless provide the opportunity for therequest to be fulfilled, determining whether policy independent of thetoken allows the request to be fulfilled. If determined 2820 that thepolicy independent of the token does not allow the request to befulfilled, the process may include denying 2816 the request. Similarly,if determined 2820 that the policy independent of the token allows therequest to be fulfilled, the process 2800 may include fulfilling 2818the request.

FIG. 29 shows an illustrative example of an environment in which variousembodiments of the present disclosure may be practiced. In particular,FIG. 29 shows an environment 2900 which utilizes caches for the purposeof updating policy and may update the caches based at least in part oninformation received in tokens that are utilized in accordance with thevarious embodiments of the present disclosure. In an embodiment, theenvironment 2900 includes one or more users, such as described above. Inaddition, the environment 2900 includes an access management servicewhich may be a computer system configured to perform various accessmanagement operations in accordance with various embodiments. Forexample, in an embodiment, the environment 2900 is part of a largerenvironment of a computing resource provider. The access managementservice may be utilized to securely control access to resources of acomputing resource provider by creating and managing users and groupsand use permissions to allow and deny access to various resources.

As illustrated in FIG. 29, the access management service is configuredto receive information from a user and provide appropriate policyupdates to an authorization master database. In an embodiment, theauthorization master database is a computer system that manages datastorage to store information representing the various policies managedby the access management service. The authorization master database maybe configured to provide, such as in response to a query, the policyupdate to a policy propagation system which is configured to providepolicy updates to applicable nodes in the environment 2900, which areillustrated as authorization and runtime service nodes. Authorizationruntime service nodes may be nodes that enable services of the computingresource provider or other entity utilizing environment 2900 to makeauthorization decisions based at least in part on policy. For example,each of multiple services provided by a computing resource provider mayinclude one or more of their own authorization runtime service nodes,each of which may have a copy of applicable policies, that is, policiesapplicable to the service. An authorization runtime client of theservice may interact with the authorization runtime service node to makesuch determinations. In addition, for the purpose of more efficientdeterminations to improve the time at which such determinations may bemade, the authorization runtime client may interact with anauthorization cache which caches policies in accordance with variouscaching rules. The authorization runtime client may check the cachebefore requesting information from an authorization runtime servicenode.

Also, as illustrated in FIG. 29, the environment 2900 includes acomputing resource service node which may be a host from which a userinteracts to submit and receive responses to requests. It should benoted that while illustrated as separate, the authorization runtimeclient may be a component of a computer resource service node. Forexample, while illustrator is a separate system, the authorizationruntime client may be an application executing on a computing resourceservice node. It should be noted that the environment 2900 may becombined with other environments described herein. For example, theuppermost user illustrated in FIG. 29 may be the resource managementsystem described above in connection with FIG. 25. The lower userillustrated in FIG. 29 may be the computing resource that received thetoken from the resource management system as illustrated in FIG. 25. Itshould be noted, however, that FIG. 29 is intended to illustrate variousconcepts more generally than the specific environment illustrated inFIG. 25.

As illustrated in FIG. 25, a user provides a policy update through theaccess management service. The access management service, as a result,both provides a policy update to the authorization master database andprovides a token, such as described above, to the user that provided thepolicy update. The policy propagation system may request policy updatesfrom a queue from the authorization master database and propagate thepolicy update through various authorization runtime service nodes toenable the authorization runtime service nodes to make determinationsabout request authenticity in response to requests from an authorizationruntime client. When a computing resource service node receives acomputing resource request with a token from a user which may be theuser that made a policy update or a different user, the computingresource service node may communicate with the authorization runtimeclient (illustrated as an authorization request in the figure) providingthe authorization runtime client information from which theauthorization runtime client can make a determination whether therequest is authentic, that is, whether the request should be fulfilled.For example, the computing resource service node can provide theauthorization runtime client the token or information extractedtherefrom and other relevant information, such as an identity of theuser making the request.

The authorization runtime client may determine how to respond to anauthorization request depending on what information it has available.For example, as appropriate, the authorization runtime client can obtaininformation from its authorization cache or, if sufficient informationis not cached in the authorization cache, the authorization client canforward the authorization request to an authorization runtime servicenode for a determination of whether the request from the user should befulfilled or denied. If the token is valid, the authorization runtimeclient may provide a response to the computing resource service nodethat fulfilling the request by the user is allowed. Similarly, ifdetermined that the token is invalid (or otherwise that the request fromthe user should be denied), the authorization runtime client may providea response to the computing resource service node that the request fromthe user should be denied. In some embodiments, when the authorizationruntime client receives a token that encodes a policy, the authorizationruntime client may update its authorization cache. Updating theauthorization cache may be dependent on the token being valid and/orauthentic. The updated policy in the authorization cache may include anexpiration value that enables the authorization cache to expunge theupdated policy from the cache. When an authorization runtime servicenode receives the same policy update through the policy propagationsystem and when an authorization runtime client submits an authorizationrequest to an authorization runtime service node, the authorizationruntime client may update the authorization cache with the policy and/ora new expiration for the policy.

FIG. 30 shows an illustrative example of a process 3000 that may be usedto process requests, in accordance with various embodiments. The process3000 may be performed, for example, by an authorization runtime client,such as described above in connection with FIG. 29, to respond toauthorization requests. Further, if considering the authorizationruntime client and the computing resource service node collectively as asingle entity (e.g., when the computing resource service node and theauthorization runtime client are part of a single device or are part ofa network and operating collectively), the process 3000 can be thoughtof performed collectively by the computing resource service node and theauthorization runtime client to respond to user requests. For thepurpose of illustration, however, the process 3000 will be described asbeing performed by the authorization runtime client or another deviceperforming a similar role.

In an embodiment, the process 3000 includes receiving 3002 a requestwith a token (or otherwise receiving a token in connection with arequest). As noted, the request may be received from a node of a servicethat needs to determine how to process a request. Upon receipt 3002 ofthe token, the process 3000 may include checking 3004 a local policycache to determine if information relevant to the policy is in thepolicy cache. Accordingly, the process 3000, as illustrated, includesdetermining 3006 whether the policy cache has already been updated witha policy encoded by the token. If determined 3006 that the policy cachehas not already been updated, the process 3000 may include determining3008 whether the token is valid and authentic, such as described above.If determined 3008 that the token is valid and authentic, the process3000 may include updating 3010 a policy cache, such as an authorizationcache described above in connection with FIG. 29.

If determined 3006 that the policy cache has already been updated or ifdetermined 3008 that the token is not valid and/or authentic, theprocess 3000 may include processing 3012 the request in accordance withpolicy. Processing the request in accordance with policy may includeproviding or otherwise utilizing a determination whether policy allows arequest to be fulfilled. Referring to FIG. 29, for example, adetermination may be provided to an appropriate computing resourceservice node to enable the computing resource service node to eitherfulfill or deny the request. It should be noted that processing therequest in accordance with policy may include processing the request inaccordance with both policy encoded by the token and existing policythat is independent from the token, such as described above.

FIG. 31 illustrates aspects of an example environment 3100 forimplementing aspects in accordance with various embodiments. As will beappreciated, although a Web-based environment is used for purposes ofexplanation, different environments may be used, as appropriate, toimplement various embodiments. The environment includes an electronicclient device 3102, which can include any appropriate device operable tosend and receive requests, messages or information over an appropriatenetwork 3104 and convey information back to a user of the device.Examples of such client devices include personal computers, cell phones,handheld messaging devices, laptop computers, set-top boxes, personaldata assistants, electronic book readers and the like. The network caninclude any appropriate network, including an intranet, the Internet, acellular network, a local area network or any other such network orcombination thereof. Components used for such a system can depend atleast in part upon the type of network and/or environment selected.Protocols and components for communicating via such a network are wellknown and will not be discussed herein in detail. Communication over thenetwork can be enabled by wired or wireless connections and combinationsthereof. In this example, the network includes the Internet, as theenvironment includes a Web server 3106 for receiving requests andserving content in response thereto, although for other networks analternative device serving a similar purpose could be used as would beapparent to one of ordinary skill in the art.

The illustrative environment includes at least one application server3108 and a data store 3110. It should be understood that there can beseveral application servers, layers, or other elements, processes orcomponents, which may be chained or otherwise configured, which caninteract to perform tasks such as obtaining data from an appropriatedata store. As used herein the term “data store” refers to any device orcombination of devices capable of storing, accessing and retrievingdata, which may include any combination and number of data servers,databases, data storage devices and data storage media, in any standard,distributed or clustered environment. The application server can includeany appropriate hardware and software for integrating with the datastore as needed to execute aspects of one or more applications for theclient device, handling a majority of the data access and business logicfor an application. The application server provides access controlservices in cooperation with the data store and is able to generatecontent such as text, graphics, audio and/or video to be transferred tothe user, which may be served to the user by the Web server in the formof HyperText Markup Language (“HTML”), Extensible Markup Language(“XML”) or another appropriate structured language in this example. Thehandling of all requests and responses, as well as the delivery ofcontent between the client device 3102 and the application server 3108,can be handled by the Web server. It should be understood that the Weband application servers are not required and are merely examplecomponents, as structured code discussed herein can be executed on anyappropriate device or host machine as discussed elsewhere herein.

The data store 3110 can include several separate data tables, databasesor other data storage mechanisms and media for storing data relating toa particular aspect. For example, the data store illustrated includesmechanisms for storing production data 3112 and user information 3116,which can be used to serve content for the production side. The datastore also is shown to include a mechanism for storing log data 3114,which can be used for reporting, analysis or other such purposes. Itshould be understood that there can be many other aspects that may needto be stored in the data store, such as for page image information andto access right information, which can be stored in any of the abovelisted mechanisms as appropriate or in additional mechanisms in the datastore 3110. The data store 3110 is operable, through logic associatedtherewith, to receive instructions from the application server 3108 andobtain, update or otherwise process data in response thereto. In oneexample, a user might submit a search request for a certain type ofitem. In this case, the data store might access the user information toverify the identity of the user and can access the catalog detailinformation to obtain information about items of that type. Theinformation then can be returned to the user, such as in a resultslisting on a Web page that the user is able to view via a browser on theuser device 3102. Information for a particular item of interest can beviewed in a dedicated page or window of the browser.

Each server typically will include an operating system that providesexecutable program instructions for the general administration andoperation of that server and typically will include a computer-readablestorage medium (e.g., a hard disk, random access memory, read onlymemory, etc.) storing instructions that, when executed by a processor ofthe server, allow the server to perform its intended functions. Suitableimplementations for the operating system and general functionality ofthe servers are known or commercially available and are readilyimplemented by persons having ordinary skill in the art, particularly inlight of the disclosure herein.

The environment in one embodiment is a distributed computing environmentutilizing several computer systems and components that areinterconnected via communication links, using one or more computernetworks or direct connections. However, it will be appreciated by thoseof ordinary skill in the art that such a system could operate equallywell in a system having fewer or a greater number of components than areillustrated in FIG. 31. Thus, the depiction of the system 3100 in FIG.31 should be taken as being illustrative in nature and not limiting tothe scope of the disclosure.

The various embodiments further can be implemented in a wide variety ofoperating environments, which in some cases can include one or more usercomputers, computing devices or processing devices which can be used tooperate any of a number of applications. User or client devices caninclude any of a number of general purpose personal computers, such asdesktop or laptop computers running a standard operating system, as wellas cellular, wireless and handheld devices running mobile software andcapable of supporting a number of networking and messaging protocols.Such a system also can include a number of workstations running any of avariety of commercially-available operating systems and other knownapplications for purposes such as development and database management.These devices also can include other electronic devices, such as dummyterminals, thin-clients, gaming systems and other devices capable ofcommunicating via a network.

Most embodiments utilize at least one network that would be familiar tothose skilled in the art for supporting communications using any of avariety of commercially-available protocols, such as TransmissionControl Protocol/Internet Protocol (“TCP/IP”), Open SystemInterconnection (“OSI”), File Transfer Protocol (“FTP”), Universal Plugand Play (“UpnP”), Network File System (“NFS”), Common Internet FileSystem (“CIFS”) and AppleTalk. The network can be, for example, a localarea network, a wide-area network, a virtual private network, theInternet, an intranet, an extranet, a public switched telephone network,an infrared network, a wireless network and any combination thereof.

In embodiments utilizing a Web server, the Web server can run any of avariety of server or mid-tier applications, including Hypertext TransferProtocol (“HTTP”) servers, FTP servers, Common Gateway Interface (“CGI”)servers, data servers, Java servers and business application servers.The server(s) also may be capable of executing programs or scripts inresponse requests from user devices, such as by executing one or moreWeb applications that may be implemented as one or more scripts orprograms written in any programming language, such as Java®, C, C# orC++, or any scripting language, such as Perl, Python or TCL, as well ascombinations thereof. The server(s) may also include database servers,including without limitation those commercially available from Oracle®,Microsoft®, Sybase® and IBM®.

The environment can include a variety of data stores and other memoryand storage media as discussed above. These can reside in a variety oflocations, such as on a storage medium local to (and/or resident in) oneor more of the computers or remote from any or all of the computersacross the network. In a particular set of embodiments, the informationmay reside in a storage-area network (“SAN”) familiar to those skilledin the art. Similarly, any necessary files for performing the functionsattributed to the computers, servers or other network devices may bestored locally and/or remotely, as appropriate. Where a system includescomputerized devices, each such device can include hardware elementsthat may be electrically coupled via a bus, the elements including, forexample, at least one central processing unit (“CPU”), at least oneinput device (e.g., a mouse, keyboard, controller, touch screen orkeypad) and at least one output device (e.g., a display device, printeror speaker). Such a system may also include one or more storage devices,such as disk drives, optical storage devices and solid-state storagedevices such as random access memory (“RAM”) or read-only memory(“ROM”), as well as removable media devices, memory cards, flash cards,etc.

Such devices also can include a computer-readable storage media reader,a communications device (e.g., a modem, a network card (wireless orwired), an infrared communication device, etc.) and working memory asdescribed above. The computer-readable storage media reader can beconnected with, or configured to receive, a computer-readable storagemedium, representing remote, local, fixed and/or removable storagedevices as well as storage media for temporarily and/or more permanentlycontaining, storing, transmitting and retrieving computer-readableinformation. The system and various devices also typically will includea number of software applications, modules, services or other elementslocated within at least one working memory device, including anoperating system and application programs, such as a client applicationor Web browser. It should be appreciated that alternate embodiments mayhave numerous variations from that described above. For example,customized hardware might also be used and/or particular elements mightbe implemented in hardware, software (including portable software, suchas applets) or both. Further, connection to other computing devices suchas network input/output devices may be employed.

Storage media and computer readable media for containing code, orportions of code, can include any appropriate media known or used in theart, including storage media and communication media, such as but notlimited to volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage and/or transmissionof information such as computer readable instructions, data structures,program modules or other data, including RAM, ROM, Electrically ErasableProgrammable Read-Only Memory (“EEPROM”), flash memory or other memorytechnology, Compact Disc Read-Only Memory (“CD-ROM”), digital versatiledisk (DVD) or other optical storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices or any othermedium which can be used to store the desired information and which canbe accessed by the a system device. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the variousembodiments.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims.

Other variations are within the spirit of the present disclosure. Thus,while the disclosed techniques are susceptible to various modificationsand alternative constructions, certain illustrated embodiments thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit theinvention to the specific form or forms disclosed, but on the contrary,the intention is to cover all modifications, alternative constructionsand equivalents falling within the spirit and scope of the invention, asdefined in the appended claims.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosed embodiments (especially in thecontext of the following claims) are to be construed to cover both thesingular and the plural, unless otherwise indicated herein or clearlycontradicted by context. The terms “comprising,” “having,” “including,”and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. The term“connected” is to be construed as partly or wholly contained within,attached to, or joined together, even if there is something intervening.Recitation of ranges of values herein are merely intended to serve as ashorthand method of referring individually to each separate valuefalling within the range, unless otherwise indicated herein and eachseparate value is incorporated into the specification as if it wereindividually recited herein. All methods described herein can beperformed in any suitable order unless otherwise indicated herein orotherwise clearly contradicted by context. The use of any and allexamples, or exemplary language (e.g., “such as”) provided herein, isintended merely to better illuminate embodiments of the invention anddoes not pose a limitation on the scope of the invention unlessotherwise claimed. No language in the specification should be construedas indicating any non-claimed element as essential to the practice ofthe invention.

Preferred embodiments of this disclosure are described herein, includingthe best mode known to the inventors for carrying out the invention.Variations of those preferred embodiments may become apparent to thoseof ordinary skill in the art upon reading the foregoing description. Theinventors expect skilled artisans to employ such variations asappropriate and the inventors intend for the invention to be practicedotherwise than as specifically described herein. Accordingly, thisinvention includes all modifications and equivalents of the subjectmatter recited in the claims appended hereto as permitted by applicablelaw. Moreover, any combination of the above-described elements in allpossible variations thereof is encompassed by the invention unlessotherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications and patents,cited herein are hereby incorporated by reference to the same extent asif each reference were individually and specifically indicated to beincorporated by reference and were set forth in its entirety herein.

What is claimed is:
 1. A computer-implemented method, comprising:initiating propagation of a security policy to a plurality of computingdevices each being operable to enforce policies in connection with aweb-based service; generating a token comprising the security policy;providing the token to a user of the web-based service based at least inpart on the security policy applying to the user; and causing a memberof the plurality of computing devices to use the token to determine togrant the user access to the web-based service in response to a request,wherein the member, upon receipt of the request and after thepropagation of the security policy has been initiated, has yet toreceive the security policy.
 2. The computer-implemented method of claim1, wherein causing the member of the plurality of computing devices togrant the user access to the web-based service comprises causing themember to make a determination depending at least in part on determiningwhether the token is valid and whether the security policy allowsfulfillment of the request.
 3. The computer-implemented method of claim2, wherein determining whether the token is valid includes determiningthat an electronic signature of the token has been signed using a keycorresponding to an entity authorized to provide the token.
 4. Thecomputer-implemented method of claim 2, wherein: the web-based serviceis a cryptography service that manages a cryptographic key; and grantingthe user access to the web-based service comprises causing thecryptography service to use the cryptographic key to decrypt ciphertext.5. The computer-implemented method of claim 4, wherein the token furthercomprises associated data for an authenticated encryption cipher, theassociated data being necessary for decryption of the ciphertext by theauthenticated encryption cipher.
 6. The computer-implemented method ofclaim 1, wherein the token further comprises one or more identifiers ofone or more principals affected by the security policy.
 7. A system,comprising: one or more processors; and memory including instructionsthat, as a result of being executed by the one or more processors, causethe system to: receive, in connection with a request to access aresource, a token comprising a policy update that the system has yet toreceive from a second system authorized to update policies; determinethe token is valid, depending at least in part on whether the policyupdate of the token is superseded by an update from the second system;as a result of determining that the token is valid, enable access to theresource in accordance with the policy update of the token; andinvalidate the token for use with the system after the policy update isapplied.
 8. The system of claim 7, wherein the instructions furthercause the system to update a local policy cache to allow, for an amountof time, access to the resource in accordance with the policy update ofthe token before the policy update is received from the systemauthorized to update policies.
 9. The system of claim 7, wherein: theresource includes a cryptographic key; and the instructions that causethe system to enable access to the resource include instructions thatcause the system to perform one or more cryptographic operations usingthe cryptographic key without providing the cryptographic key inplaintext form.
 10. The system of claim 7, wherein the instructions thatcause the system to enable access to the resource in accordance with thepolicy update of the token include instructions that cause the system torequire the policy update to not be superseded by a more recent policyupdate received after the token was generated.
 11. The system of claim10, wherein the token further comprises one or more values that enablethe system to determine whether the policy update of the token is valid.12. The system of claim 7, wherein: the instructions further cause thesystem to determine whether the token is authentic; and the instructionsthat cause the system to enable access to the resource in accordancewith the policy update indicated by the token are executed as a resultof determining that the token is authentic.
 13. The system of claim 7,wherein the request is a web services request.
 14. A non-transitorycomputer-readable storage medium having stored thereon instructionsthat, if executed by one or more processors of a computer system, causethe computer system to: initiate propagation of a security policy to aplurality of computing devices each being operable to enforce policiesin connection with a resource of a web-based service; generate a tokencomprising the security policy; provide the token to a user of theweb-based service based at least in part on the security policy applyingto the user; and cause a member of the plurality of computing devices touse the token to determine to grant the user access to the resource inresponse to a request, wherein the member, upon receipt of the requestand after the propagation of the security policy has been initiated, hasyet to receive the security policy.
 15. The non-transitorycomputer-readable storage medium of claim 14, wherein: the securitypolicy affects access of a computing system instance to a cryptographickey under which another cryptographic key is encrypted; the othercryptographic key is usable to decrypt data stored on a data storagedevice logically attached to the computer system instance; and theinstructions that provide access to the resource include instructionsthat cause a cryptography service that manages the cryptographic key touse the cryptographic key to decrypt and provide the other cryptographickey without exposing the cryptographic key in plaintext form.
 16. Thenon-transitory computer-readable storage medium of claim 14, wherein thetoken includes a value that enables the member of the plurality ofcomputing devices to determine that another policy change made aftergeneration of the token does not contradict the token.
 17. Thenon-transitory computer-readable storage medium of claim 14, wherein:the resource is a cryptographic key managed by a cryptography servicethat is configured to use the cryptographic key in an authenticatedencryption cipher; and the token further comprises associated datanecessary for successful use of the cryptographic key in theauthenticated encryption cipher.
 18. The non-transitorycomputer-readable storage medium of claim 14, wherein the system,resource, and one or more principals are hosted by a computing resourceprovider on behalf of a customer of a plurality of customers of thecomputing resource provider.
 19. The non-transitory computer-readablestorage medium of claim 18, wherein the system is a management system ofa service and the one or more principals are computing resources managedby the management system.
 20. The non-transitory computer-readablestorage medium of claim 14, wherein the resource is selected from thegroup consisting of a block-level data storage device, a data objectstored by a data storage service, a computer system of a programexecution service, a cache of a caching service, and a cryptographic keymanaged by a cryptography service.